home *** CD-ROM | disk | FTP | other *** search
/ MacTech 1 to 12 / MacTech-vol-1-12.toast / Reference / the cmsp digests ('94-'97) / csmp digest Vol 3 No 054 < prev    next >
Encoding:
Internet Message Format  |  1997-05-06  |  87.2 KB  |  [TEXT/R*ch]

  1. From: pottier@clipper.ens.fr (Francois Pottier)
  2. Subject: csmp-digest-v3-054
  3. Date: Wed, 7 Sep 1994 18:19:19 +0200 (MET DST)
  4.  
  5. C.S.M.P. Digest             Wed, 07 Sep 94       Volume 3 : Issue 54
  6.  
  7. Today's Topics:
  8.  
  9.         How to use AESuspendTheCurrentEvent?
  10.         Learning Macintosh Programming
  11.         Should function order be conserved? (CW vs. GestaltValue)
  12.         Sound Manager headaches (again)
  13.         Stopping a 'snd ' resource dead
  14.         [Q] What does "_Xxxxx ,Sys,Immed" mean?
  15.         jGNE from an INIT
  16.  
  17.  
  18.  
  19. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  20. (pottier@clipper.ens.fr).
  21.  
  22. The digest is a collection of article threads from the internet newsgroup
  23. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  24. regularly and want an archive of the discussions.  If you don't know what a
  25. newsgroup is, you probably don't have access to it.  Ask your systems
  26. administrator(s) for details.  If you don't have access to news, you may
  27. still be able to post messages to the group by using a mail server like
  28. anon.penet.fi (mail help@anon.penet.fi for more information).
  29.  
  30. Each issue of the digest contains one or more sets of articles (called
  31. threads), with each set corresponding to a 'discussion' of a particular
  32. subject.  The articles are not edited; all articles included in this digest
  33. are in their original posted form (as received by our news server at
  34. nef.ens.fr).  Article threads are not added to the digest until the last
  35. article added to the thread is at least two weeks old (this is to ensure that
  36. the thread is dead before adding it to the digest).  Article threads that
  37. consist of only one message are generally not included in the digest.
  38.  
  39. The digest is officially distributed by two means, by email and ftp.
  40.  
  41. If you want to receive the digest by mail, send email to listserv@ens.fr
  42. with no subject and one of the following commands as body:
  43.     help                        Sends you a summary of commands
  44.     subscribe csmp-digest Your Name    Adds you to the mailing list
  45.     signoff csmp-digest            Removes you from the list
  46. Once you have subscribed, you will automatically receive each new
  47. issue as it is created.
  48.  
  49. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  50. Questions related to the ftp site should be directed to
  51. scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
  52. digest are available there.
  53.  
  54. Also, the digests are available to WAIS users.  To search back issues
  55. with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
  56. http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.
  57.  
  58.  
  59. -------------------------------------------------------
  60.  
  61. >From phaedrus@chinook.halcyon.com (Mark Phaedrus)
  62. Subject: How to use AESuspendTheCurrentEvent?
  63. Date: 19 Aug 1994 21:44:57 GMT
  64. Organization: NWNEXUS, Inc. - Making Internet Easy
  65.  
  66.      Could someone please post some brief sample code showing the correct use
  67. of AESuspendTheCurrentEvent and AEResumeTheCurrentEvent?
  68.      Basically, this is what I'm doing right now:
  69.  
  70. AppleEvent *pendingEvent,*pendingReply;
  71. OSErr err;
  72.  
  73. pascal OSErr MyEventHandler(AppleEvent *messagein, AppleEvent *reply,
  74.                             long refcon)
  75. {
  76.    /* make sure we're allowed to put up a window */
  77.    if (noErr != (err = AEInteractWithUser(kMyTimeoutTicks,nil,nil)))
  78.         return err;
  79.    /* assorted code to display the window deleted */
  80.    /* keep track of these events for later */
  81.    pendingEvent = messagein;
  82.    pendingReply = reply;
  83.    /* we'll wait for the user to do something that triggers a response */
  84.    if (noErr != (err = AESuspendTheCurrentEvent(messagein)))
  85.        return err;
  86.    return noErr;
  87. }
  88.  
  89. pascal OSErr MyEventCompletion(AppleEvent *messagein,AppleEvent *reply,
  90.                                long refcon)
  91. {
  92.      AEPutParamPtr(reply,keyAEResult,typeChar,(Ptr)myStuff,strlen(myStuff));
  93.      return noErr;
  94. }
  95.  
  96. void CodeCalledWhenReadyToFinish(void)
  97. {
  98.    err = AEResumeTheCurrentEvent(pendingEvent,pendingReply,MyEventCompletion,
  99.                                  0);
  100. }
  101.  
  102.     When the event handler is called, AESuspendTheCurrentEvent returns noErr,
  103. and the event is apparently suspended correctly; at least, the caller never
  104. gets a reply, even though the event handler returns.  The problem is that the
  105. event and reply records seem to be getting disposed immediately; pendingEvent
  106. and pendingReply are pointing at garbage when CodeCalledWhenReadyToFinish is
  107. called, and as a result AEResumeTheCurrentEvent fails miserably.
  108.     Any help you can give is gratefully appreciated...
  109.  
  110.  
  111. --
  112. \o\   If you're interested in books/stories with transformation    \o\
  113.  \o\themes, or in furry/anthropomorphic art, email me, or anonymous-\o\
  114.   \o\ftp to ftp.halcyon.com and check the /local/phaedrus directory. \o\
  115.    \o\ Web users:  Now try http://www.halcyon.com/phaedrus/Menu.html  \o\
  116.  
  117. +++++++++++++++++++++++++++
  118.  
  119. >From hanrek@cts.com (Mark Hanrek)
  120. Date: 22 Aug 1994 04:54:34 GMT
  121. Organization: The Information Workshop
  122.  
  123. In article <33394p$cs5@news.halcyon.com>, phaedrus@chinook.halcyon.com
  124. (Mark Phaedrus) wrote:
  125.  
  126. >      Could someone please post some brief sample code showing the correct use
  127. > of AESuspendTheCurrentEvent and AEResumeTheCurrentEvent?
  128. >      Basically, this is what I'm doing right now:
  129.  
  130. There is some example source code called "SuspendAppleEvent" that will
  131. hopefully help.
  132.  
  133. You will find under "Inter-Application Communication" within the Snippets
  134. collection.  It is on the Developer CD and hopefully available at
  135. ftp://ftp.apple.com/ as well.
  136.  
  137. Mark Hanrek
  138.  
  139. +++++++++++++++++++++++++++
  140.  
  141. >From bb@lightside.com (Bob Bradley)
  142. Date: Sun, 21 Aug 1994 04:13:05 -0800
  143. Organization: SS Software Inc.
  144.  
  145. I don't have a question of how to use AESuspendTheCurrentEvent but,
  146. whether I should use it. When I receive an OpenDoc event, I put up a
  147. dialog and the files attached to the OpenDoc event do not get processed
  148. until the user hits ok in the dialog (or cancel which would not process
  149. the documents at all). Should I suspend the OpenDoc event and resume when
  150. (or if) the user chooses ok in the dialog or should I just let the
  151. AppleEvent return and process the documents when the user wants?
  152.  
  153. IM Interapp Comm says the AppleEvent Manager expects the event to have
  154. been processed when the handler returns which it wouldn't have been in my
  155. case and I'm not sure if I should call AESuspendTheCurrentEvent (and
  156. resume it later). It works fine though.
  157.  
  158. +++++++++++++++++++++++++++
  159.  
  160. >From paul@architecture.mcgill.ca (Paul Lalonde)
  161. Date: Tue, 23 Aug 1994 02:28:45 GMT
  162. Organization: McGill University School of Architecture
  163.  
  164. In article <33394p$cs5@news.halcyon.com>, phaedrus@chinook.halcyon.com
  165. (Mark Phaedrus) wrote:
  166.  
  167. >      Could someone please post some brief sample code showing the correct use
  168. > of AESuspendTheCurrentEvent and AEResumeTheCurrentEvent?
  169. >      Basically, this is what I'm doing right now:
  170.  
  171. > [ stuff deleted ]
  172.  
  173. You have to save the actual event and reply records, not just pointers to 
  174. them.  So a revised version of the snippet you posted would look like this:
  175.  
  176. AppleEvent pendingEvent,pendingReply;
  177.  
  178. pascal OSErr MyEventHandler(AppleEvent *messagein, AppleEvent *reply,
  179.                             long refcon)
  180. {
  181.    /* stuff deleted */
  182.    pendingEvent = *messagein;
  183.    pendingReply = *reply;
  184.    /* more stuff deleted */
  185.    return noErr;
  186. }
  187.  
  188. void CodeCalledWhenReadyToFinish(void)
  189. {
  190.    err = AEResumeTheCurrentEvent(&pendingEvent,&pendingReply,
  191.                                  MyEventCompletion,0);
  192. }
  193.  
  194.  
  195. Hope this helps,
  196.  
  197. Paul Lalonde
  198. paul@architecture.mcgill.ca
  199.  
  200. ---------------------------
  201.  
  202. >From dchakrav@netserv.unmc.edu (Dhruba Chakravarti)
  203. Subject: Learning Macintosh Programming
  204. Date: 19 Aug 1994 11:23:44 -0500
  205. Organization: University of Nebraska Medical Center, Omaha, NE, USA
  206.  
  207. I do not know anything about programming, which should be obvious
  208. from the header.  I have a Macintosh computer and would like to
  209. learn programming for Macintosh.  Please advise me.
  210.  
  211. Regards,
  212.  
  213. Dhruba.
  214.  
  215.  
  216. +++++++++++++++++++++++++++
  217.  
  218. >From mathews@ns9000.furman.edu (Owen Mathews)
  219. Date: 19 Aug 1994 18:50:13 GMT
  220. Organization: furman university computing center
  221.  
  222. Dhruba Chakravarti (dchakrav@netserv.unmc.edu) wrote:
  223. : I do not know anything about programming, which should be obvious
  224. : from the header.  I have a Macintosh computer and would like to
  225. : learn programming for Macintosh.  Please advise me.
  226.  
  227. : Regards,
  228.  
  229. : Dhruba.
  230.  
  231. If you're programming in Pascal, pick up the
  232.  
  233.     -Macintosh Pascal Programming Primer
  234.      by Dave Mark and ??? Reed (something like that)
  235.     **good introductory Mac book; teaches all about the Toolbox
  236.     and Mac programming fundamentals; comes with several well-thought-out
  237.     example programs to get you started
  238.  
  239. If you're using C, then try
  240.  
  241.     -Macintosh C Programming Primer
  242.      same fellow(s?)
  243.     **I haven't see this one, but I assume it's the same idea.
  244.  
  245. If you're really ambitious, take a look at
  246.  
  247.     -Learn C++ on the Macintosh
  248.      guess who?  (I'm a real admirer of this guy)
  249.     **Also probably the same basic idea.
  250.  
  251. No matter which language you use, you'll eventually want to invest in
  252.  
  253.     -Inside Macintosh
  254.      Apple Computer
  255.     **This set of reference books is the ultimate authority on all
  256.     aspects of Mac programming.  It comes in two flavors:  Old Inside Mac
  257.     (IM) and New IM (NIM).  Old IM comes in 6 volumes that are organized
  258.     chronologically.  This unfortunately means that certain related material
  259.     can be spread out over multiple volumes, forcing you to spend extra
  260.     time to find the right volume.  NIM groups material logically by
  261.     subject.  Each volume covers some clearly-defined area of the Mac API.
  262.     Of course, NIM's disadvantage is that when Apple releases new stuff,
  263.     you can't go and pick up the next chronological volume -- instead,
  264.     you'll probably have to go and buy half a dozen updates to the subject
  265.     volumes.
  266.     But I'm rambling.
  267.  
  268. Hey, don't let all that talk daunt you.  With any of the first three books,
  269. you can get started programming quickly and produce your first (albeit ultra-
  270. simple) Mac application within an hour or two.
  271.  
  272. Hope this helps!
  273.  
  274. --
  275.        Owen Mathews    mathews@furman.edu
  276.        <><><><><><><><><><><><><><><><><><><><>
  277.        Furman University, Computer Science Dept
  278.  
  279. +++++++++++++++++++++++++++
  280.  
  281. >From dchakrav@netserv.unmc.edu (Dhruba Chakravarti)
  282. Date: 19 Aug 1994 17:17:42 -0500
  283. Organization: University of Nebraska Medical Center, Omaha, NE, USA
  284.  
  285. Owen Mathews (mathews@ns9000.furman.edu) wrote:
  286. : Dhruba Chakravarti (dchakrav@netserv.unmc.edu) wrote:
  287. : : I do not know anything about programming, which should be obvious
  288. : : from the header.  I have a Macintosh computer and would like to
  289. : : learn programming for Macintosh.  Please advise me.
  290.  
  291. : : Regards,
  292.  
  293. : : Dhruba.
  294.  
  295. : If you're programming in Pascal, pick up the
  296.  
  297. :     -Macintosh Pascal Programming Primer
  298. :      by Dave Mark and ??? Reed (something like that)
  299. :     **good introductory Mac book; teaches all about the Toolbox
  300. :     and Mac programming fundamentals; comes with several well-thought-out
  301. :     example programs to get you started
  302.  
  303. : If you're using C, then try
  304.  
  305. :     -Macintosh C Programming Primer
  306. :      same fellow(s?)
  307. :     **I haven't see this one, but I assume it's the same idea.
  308.  
  309. : If you're really ambitious, take a look at
  310.  
  311. :     -Learn C++ on the Macintosh
  312. :      guess who?  (I'm a real admirer of this guy)
  313. :     **Also probably the same basic idea.
  314.  
  315. : No matter which language you use, you'll eventually want to invest in
  316.  
  317. :     -Inside Macintosh
  318. :      Apple Computer
  319. :     **This set of reference books is the ultimate authority on all
  320. :     aspects of Mac programming.  It comes in two flavors:  Old Inside Mac
  321. :     (IM) and New IM (NIM).  Old IM comes in 6 volumes that are organized
  322. :     chronologically.  This unfortunately means that certain related material
  323. :     can be spread out over multiple volumes, forcing you to spend extra
  324. :     time to find the right volume.  NIM groups material logically by
  325. :     subject.  Each volume covers some clearly-defined area of the Mac API.
  326. :     Of course, NIM's disadvantage is that when Apple releases new stuff,
  327. :     you can't go and pick up the next chronological volume -- instead,
  328. :     you'll probably have to go and buy half a dozen updates to the subject
  329. :     volumes.
  330. :     But I'm rambling.
  331.  
  332. : Hey, don't let all that talk daunt you.  With any of the first three books,
  333. : you can get started programming quickly and produce your first (albeit ultra-
  334. : simple) Mac application within an hour or two.
  335.  
  336. : Hope this helps!
  337.  
  338. : --
  339. :        Owen Mathews    mathews@furman.edu
  340. :        <><><><><><><><><><><><><><><><><><><><>
  341. :        Furman University, Computer Science Dept
  342.  
  343. Thank you very much!  I'll get these books and start reading.
  344.  
  345. Regards,
  346.  
  347. Dhruba.
  348.  
  349.  
  350. +++++++++++++++++++++++++++
  351.  
  352. >From Chris Kueny <yun@fusion.ph.utexas.edu>
  353. Date: 19 Aug 1994 23:37:21 GMT
  354. Organization: The University of Texas at Austin, Austin, Texas
  355.  
  356. In article <332mag$2jq@netserv.unmc.edu> Dhruba Chakravarti,
  357. dchakrav@netserv.unmc.edu writes:
  358.  
  359. >I do not know anything about programming, which should be obvious
  360. >from the header.  I have a Macintosh computer and would like to
  361. >learn programming for Macintosh.  Please advise me.
  362.  
  363. The C Programming Primer by Dave Mark assumes that you
  364. know something about the C programming language (and I 
  365. assume that the Pascal Programming Primer assumes knowledge
  366. of Pascal.) Another good book at this level is Dan Parks Sydow's
  367. "Macintosh Programming Techniques".
  368.  
  369. But if you have no programming experience at all, then a good
  370. one to start with is "Learn C on the Macintosh" by Dave Mark.
  371. This has a stripped down version of Symantec's Think C compiler
  372. that can be used to run the projects in the book. It will give you
  373. an introduction to the C language, but won't tell you everything.
  374. It has a good explanation of programming concepts for people
  375. who have never done such things before. As mentioned above,
  376. Dave also wrote "Learn C++ on the Macintosh".
  377.  
  378. A classic reference for the whole C language is "The C Programming
  379. Language" by Kernighan & Ritchie.
  380.  
  381. I don't have much knowledge of Pascal. I think I heard someone
  382. say that it is easier for a beginner to learn Pascal than to learn C.
  383.  
  384. Eventually you will have to buy a compiler. C and Pascal compilers
  385. are available at good discounts for university and college students
  386. and staff (maybe younger students too?) Used ones are also
  387. sometimes advertised in this newsgroup.
  388.  
  389. +++++++++++++++++++++++++++
  390.  
  391. >From millsp@govonca.gov.on.ca (Phil Mills)
  392. Date: Sat, 20 Aug 1994 13:05:05 GMT
  393. Organization: Government of Ontario
  394.  
  395. In <332mag$2jq@netserv.unmc.edu> dchakrav@netserv.unmc.edu (Dhruba Chakravarti) writes:
  396.  
  397. >I do not know anything about programming, which should be obvious
  398. >from the header.  I have a Macintosh computer and would like to
  399. >learn programming for Macintosh.  Please advise me.
  400.  
  401. 1) Decide why you want to program and what kind of program you would
  402. like to create.  The best choice in tools and information sources will
  403. change depending on that decision.
  404.  
  405. (Without an answer to #1, there *is* no item #2.  :-)  )
  406.  
  407. +++++++++++++++++++++++++++
  408.  
  409. >From kenlong@netcom.com (Ken Long)
  410. Date: Sat, 20 Aug 1994 16:52:14 GMT
  411. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  412.  
  413. Learn C on the Macintosh is NOT a good book for someone who has no 
  414. programming or Mac programming experience.  It contains LITTLE about what 
  415. new Mac programmers are interested in.
  416.  
  417. Think THINK C!, by Dan Parks Sydow is THE book to start with.  It teaches 
  418. new Mac programmers about aspects of Mac programming they WANT to know about.
  419.  
  420. -Ken-
  421.  
  422. +++++++++++++++++++++++++++
  423.  
  424. >From silicon@Simplex.NL (Silicon Island Software)
  425. Date: 21 Aug 1994 08:28:13 GMT
  426. Organization: Simplex Networking Amsterdam, The Netherlands.
  427.  
  428. Dhruba Chakravarti (dchakrav@netserv.unmc.edu) wrote:
  429. : I do not know anything about programming, which should be obvious
  430. : from the header.  I have a Macintosh computer and would like to
  431. : learn programming for Macintosh.  Please advise me.
  432.  
  433.  
  434. Why Visual EzC is good for learning Macintosh programming.
  435.  
  436. When you program in EzC, the Layouts of the applications with
  437. their interface elements are all created graphically in a MacDraw
  438. like Layout Editor. The process has little if anything to do with
  439. programming. 
  440.  
  441. The Menus of the application are also created in a graphic editor
  442. by simply adding menus and menu items in a list.
  443.  
  444. The EzC program code is a C-like code, with all the basic syntax
  445. and functionality the same as in normal C.
  446.  
  447. There is admittedly nothing new about creating layouts and
  448. menus graphically. - The available 4GL languages all do that, each
  449. in their own way. What is new though is, that EzC has a very
  450. powerful and well known programming language, and the EzC
  451. code can be pre-compiled into C, simply by selecting Precompile
  452. from the menu. The resulting C code can then be compiled with
  453. for instance MPW and the project can be made into a standalone
  454. application. 
  455.  
  456. Programs written in EzC are just as fast and small in size as
  457. programs written from scratch in C or Pascal.
  458.  
  459. To give the curious an example of how a simple program looks
  460. like in EzC we can take as an example a window with a text field
  461. and listbox and an accept button. When the user keys in a name
  462. in the text field and clicks the accept button the name appears in
  463. the listbox.
  464.  
  465. Solving the problem:
  466.  
  467. 1) The interface elements are drawn in the layout editor.
  468.  
  469. 2) A menu for the application is created in the menu editor.
  470.  
  471. 3) The code to do the processing is as follows:
  472.  
  473.  
  474. inherit "Std:System:Window";
  475.  
  476. string *arr;
  477.  
  478. void _OpenView()  {
  479.     arr=({});
  480.     LoadMenubar("Main");
  481. }
  482.  
  483. void _Click(string name)  {
  484.     if(name=="ok")  {
  485.        arr+=({Get("field","text")});
  486.        Set("listbox","array",arr);
  487.        Set("field","text","");
  488.     }
  489. }
  490.  
  491. The layout with the program code constitutes an object in EzC.
  492.  
  493. The explanation of the code is simple. 
  494.  
  495. In the first line we inherit the standard behaviour of a window.
  496.  
  497. EzC is event driven, and opening a window generates an event.
  498. To every EzC event corresponds a function. _OpenView() is one
  499. such function. If defined in an object, it is invoked when the
  500. event occurs. _Click() is another event handler function. It is
  501. invoked on clicking the mouse.
  502.  
  503. The interface elements have names. The text field has the been
  504. given the name 'field' and the listbox element is called 'listbox'
  505. and the accept button's name is 'ok'.
  506.  
  507. The Set() function sets a property of an interface element with
  508. given parameters, and the Get() function fetches the value of a
  509. property of an interface element.
  510.  
  511. The code is only a few lines, and this is a functioning application,
  512. and can be made standalone.
  513.  
  514. It is our opinion that EzC is a suitable language for learning
  515. Macintosh programming. - Try for instance for comparison to
  516. teach the beginner to create the above example application with
  517. Think C using the TCL library. 
  518.  
  519. The programmer does not need to study any textbook on
  520. Macintosh programming to be able create simple applications
  521. like the above application in EzC, nor does he need to have read a
  522. word of the voluminous Inside Macintosh. He does however need
  523. to know something about C programming in general and to
  524. understand the events of EzC and to have at hand a reference
  525. over the main kernel and Library functions in EzC.
  526.  
  527. As the programmer becomes more proficient Visual EzC will
  528. grow with him, since it is so strongly related to C. The
  529. programmer also gradually becomes interested in acquiring
  530. knowledge of the Macintosh Toolbox as he needs to solve more
  531. advanced problems. 
  532.  
  533. The main advantage of learning Macintosh programming by
  534. using EzC is that the beginner can actually create useful
  535. standalone applications that he can be proud of within hours.
  536.  
  537. Another important advantage is, that the beginner will quickly
  538. learn to appreciate Object Oriented programming as object
  539. orientation is so closely woven into the EzC language.
  540.  
  541. A third advantage is, that the beginner will learn the basics of a
  542. generally known and accepted language, C.
  543.  
  544. Last but not least. One should not forget that EzC also has a built
  545. in relational database engine, so when the beginner wants to
  546. create a database program, the tools are right there.
  547.  
  548. A demo of Visual EzC can be found on mac.archive.umich.edu in
  549. the /mac/misc/demo/visualezc1.0b4-demo.hqx and on any of the
  550. info-mac mirror sites.
  551.  
  552. Silicon Island Software
  553. Email: silicon@simplex.nl
  554.  
  555. +++++++++++++++++++++++++++
  556.  
  557. >From D.Birnie@Regy.Canterbury.ac.nz (Denis A. Birnie)
  558. Date: Mon, 22 Aug 1994 11:17:06 +1200
  559. Organization: ISS
  560.  
  561. > I do not know anything about programming, which should be obvious
  562. > from the header.  I have a Macintosh computer and would like to
  563. > learn programming for Macintosh.  Please advise me.
  564. Dhruba,
  565.  
  566. The current way to go language-wise is C (or C++).
  567.  
  568. The book which I'd recommend (and which uses C) is
  569. Macintosh_Programming_Secrets (2nd edition) by Scott Knaster & Keith
  570. Rollin.  Shows you all sorts of interesting and neat things as well as
  571. giving you a skeleton application to work from. A VERY good book.
  572.  
  573. I'd also suggest Think Reference if you get serious and have a screen
  574. larger than the original 9"ers.
  575.  
  576. Denis Birnie
  577. --
  578. COBOhoLic!
  579.  
  580. +++++++++++++++++++++++++++
  581.  
  582. >From hanrek@cts.com (Mark Hanrek)
  583. Date: 22 Aug 1994 05:04:10 GMT
  584. Organization: The Information Workshop
  585.  
  586. In article <332mag$2jq@netserv.unmc.edu>, dchakrav@netserv.unmc.edu
  587. (Dhruba Chakravarti) wrote:
  588.  
  589. > I do not know anything about programming, which should be obvious
  590. > from the header.  I have a Macintosh computer and would like to
  591. > learn programming for Macintosh.  Please advise me.
  592.  
  593. Dhruba,
  594.  
  595. Besides all the excellent suggestions and advice thus far, consider doing
  596. the following...
  597.  
  598. Decide on a language, and get the compiler for it.
  599.  
  600. Then, download all the example source code you can find in that language
  601. and compile it.
  602.  
  603. If something is too hard to get going, move on to another.
  604.  
  605. When you get something to compile successfully, and it runs, then maybe
  606. you can think of an easy way to tweak it or make it do something
  607. different.
  608.  
  609. - --
  610.  
  611. This method is an excellent method, because you will quickly become
  612. familiar with your development environment, and the language, and the
  613. Macintosh Toolbox (the three things you'll be learning at the same time).
  614.  
  615. But what is great about this approach is that you will be getting a sense
  616. of gratification as you go along, and you will always be modifying rather
  617. than creating -- these are two very important things in the beginning, and
  618. two of the major reasons many people give up.
  619.  
  620. There's no need to overwhelm yourself.  Always have a language reference handy.
  621.  
  622. So compile freely downloadable program right and left, have fun, make some
  623. changes that make goofy things happen, and next thing you know, you will
  624. have subliminally learned a ton of essential things without even noticing
  625. it.
  626.  
  627.  
  628. Good luck to you.
  629.  
  630. Mark Hanrek
  631. The Information Workshop
  632.  
  633. +++++++++++++++++++++++++++
  634.  
  635. >From garyg@oak.circa.ufl.edu
  636. Date: 22 Aug 1994 12:46:50 GMT
  637. Organization: Center for Instructional and Research Computing Activities
  638.  
  639. Dhruba,
  640. In addition to the other advice offered, I'd suggest that you also get:
  641. Macintosh Programming Techniques: A Foundation for All Macintosh
  642. Programmers by Dan Parks Sydow (1994; M&T Books). It includes a
  643. diskette with interactive tutorials, sample code with small built
  644. applications (in case you don't have a C compiler yet), and lots
  645. of highly useful info. Another great job by DPSydow!!
  646. hth, Gary
  647.  
  648. +++++++++++++++++++++++++++
  649.  
  650. >From dchakrav@netserv.unmc.edu (Dhruba Chakravarti)
  651. Date: 23 Aug 1994 11:27:23 -0500
  652. Organization: University of Nebraska Medical Center, Omaha, NE, USA
  653.  
  654. garyg@oak.circa.ufl.edu wrote:
  655. : Dhruba,
  656. : In addition to the other advice offered, I'd suggest that you also get:
  657. : Macintosh Programming Techniques: A Foundation for All Macintosh
  658. : Programmers by Dan Parks Sydow (1994; M&T Books). It includes a
  659. : diskette with interactive tutorials, sample code with small built
  660. : applications (in case you don't have a C compiler yet), and lots
  661. : of highly useful info. Another great job by DPSydow!!
  662. : hth, Gary
  663.  
  664.  
  665. Thank you all very much!
  666.  
  667. Regards,
  668.  
  669. Dhruba.
  670.  
  671.  
  672. ---------------------------
  673.  
  674. >From will@cs.su.oz.au (William Uther)
  675. Subject: Should function order be conserved? (CW vs. GestaltValue)
  676. Date: 20 Aug 1994 16:19:54 +1000
  677. Organization: Basser Dept of Computer Sciece, Uni of Sydney, Australia
  678.  
  679. Hi,
  680.   I am using CodeWarrior to write a small application.  I want this application
  681. to publish a handle.  I had an earlier version that did this using the
  682. GestaltValue library.  This library does not work with CW 3.5.
  683.   I traced it, and found that the reason it didn't work was because it relied
  684. upon the ordering of functions to find the size of a block of memory to
  685. allocate.  (it subtracted the address of the start of one function from the
  686. address of the start of another function to get the size of the first function
  687. and hence the amount of memory it had to allocate to copy it to the system heap)
  688.   CW 3.5 does not respect this ordering when it converts Apple's '.o' file into
  689. a library.
  690.  
  691.   Is this a problem for MetroWerks (CW SHOULD respect the function ordering),
  692. or is this a problem for Apple (DTS shouldn't write libraries that rely on
  693. function ordering)??  At the moment it just seems to be a problem for me....
  694.  
  695.   Metrowerks tech support were very good at verifying the problem,
  696. unfortunately, since they shifted the blame to Apple they haven't done much.
  697. (BTW the library works in THINK C 5.0, 6.0 and 7.0 - I assume it works in MPW
  698. as it's an MPW object file)
  699.  
  700. Should I be talking to Apple DTS or Metrowerks tech support?
  701.  
  702. \x/ill        :-}
  703.  
  704. will@cs.su.oz.au
  705.  
  706.  
  707. +++++++++++++++++++++++++++
  708.  
  709. >From cokenias@netcom.com (Damon Cokenias)
  710. Date: Sun, 21 Aug 1994 21:16:36 GMT
  711. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  712.  
  713. - ---
  714.   I traced it, and found that the reason it didn't work was because it relied
  715. upon the ordering of functions to find the size of a block of memory to
  716. allocate.  (it subtracted the address of the start of one function from the
  717. address of the start of another function to get the size of the first function
  718. and hence the amount of memory it had to allocate to copy it to the system heap)
  719.   CW 3.5 does not respect this ordering when it converts Apple's '.o' file into
  720. a library.
  721. - ---
  722.  
  723. Every time I'm stepping through somebody's INIT trying to find out if it is
  724. responsible for crashing my machine, I invariably find this sort of programming.
  725. It is sick and immoral.  It is absolutely none of the programmer's business
  726. where or how their code gets compiled.
  727.  
  728. There are two solutions to the Patch/Gestalt Selector/Shutdown Handler install
  729. problem.  (Actually, there are more than two, but these are my favorites).
  730.  
  731. ** A **
  732.  
  733. 1) Call Get1IndResource (INIT, 1) to find yourself (or other appropriate
  734.    GetResource call)
  735. 2) Detach yourself, install all patches, etc.
  736.  
  737. ** B **
  738.  
  739. 1) Load a code resource containing your patch routines, detach and lock
  740. 2) Install patches.
  741.  
  742. I typically use A for quickie jobs that I just want to crank out in a moment
  743. or two.  It has the disadvantage of leaving the loader code behind.  Some of
  744. the advantages are: Only one binary to build (nice for THINK and CW users),
  745. the patches have access to the same A4 globals the loader code did.  This
  746. can be usefull.
  747.  
  748. I choose B for lean and mean INITs that I release to the public.  In order to
  749. initialize the globals for the code resource with values from the loader, I
  750. sometimes do the following:
  751.  
  752. 1) Inside the code resource I have an A4 global called 'intialized'.  It's
  753. initial value is zero.
  754. 2) BEFORE installing the patches, I call my code resource, passing a pointer
  755. to a structure containing initial values.  This can only be done for patches
  756. that accept parameters, obviously.
  757. 3) If 'initialized' is still false, the code resource knows the passed parameter
  758. contains special data and uses that data.  'initialized' is then set to true.
  759. 4) From this point on, all calls to the code resource are treated as one would
  760. expect them to.
  761.  
  762. Often, this is the most convenient way to tell a patch where to jump to after
  763. completion.  It is 100% portable on all platforms that allow a standalone
  764. code resource to have globals.
  765.  
  766. DO NOT:
  767.   * assume code gets put anywhere.  If you use Codewarrior, the frequent
  768.     updates and changes should cure you of that fast enough.
  769.  
  770. (What if CW noticed that a particular routine could be called with a short
  771. branch instead of a long one?  It might re-arrange certain funtions to make
  772. them closer to their callers.)
  773.  
  774. -Damon Cokenias
  775. .
  776.  
  777. -- 
  778. Damon Cokenias
  779. cokenias@netcom.COM
  780.  
  781. +++++++++++++++++++++++++++
  782.  
  783. >From h+@nada.kth.se (Jon W{tte)
  784. Date: Mon, 22 Aug 1994 14:54:28 +0200
  785. Organization: Royal Institute of Something or other
  786.  
  787. In article <cokeniasCuwLro.J8@netcom.com>,
  788. cokenias@netcom.com (Damon Cokenias) wrote:
  789.  
  790. >It is sick and immoral.  It is absolutely none of the programmer's business
  791. >where or how their code gets compiled.
  792.  
  793. Yes; it definately is. For a well-defined runtime architecture, 
  794. like the Mac 68k one, you're allowed and sometimes forced to do 
  795. this.
  796.  
  797. >There are two solutions to the Patch/Gestalt Selector/Shutdown Handler install
  798. >problem.  (Actually, there are more than two, but these are my favorites).
  799.  
  800. >1) Call Get1IndResource (INIT, 1) to find yourself (or other appropriate
  801. >   GetResource call)
  802. >2) Detach yourself, install all patches, etc.
  803.  
  804. >1) Load a code resource containing your patch routines, detach and lock
  805. >2) Install patches.
  806.  
  807. Strangely enough, I use none of these. Instead, I get the 
  808. address of the first instruction (you can use A0 as well, but 
  809. it's slightly less safe - someone COULD have jumped to you 
  810. through another register) Then I call RecoverHandle and 
  811. DetachResource, and use PC-relative addressing to install my 
  812. patches (and store data) This requires your INIT to be marked 
  813. pre-loaded, system heap and locked.
  814.  
  815. >1) Inside the code resource I have an A4 global called 'intialized'.  It's
  816.  
  817. A4 globals are much more horrible than comparing addresses of 
  818. functions. A4 globals require you to always enter through 
  819. main(), unless you do extra inline assembly, which kind of 
  820. rules out the case where the loader and the patch are in the 
  821. same code resource.
  822.  
  823. PS: you can get by the loader-left problem by putting the 
  824. loader code last, branch to it from the top and then call 
  825. SetHandleSize.
  826.  
  827.  
  828.  
  829.  
  830. --
  831.   Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  832.  "Don't Deal with a Dragon."
  833.  
  834.  
  835. +++++++++++++++++++++++++++
  836.  
  837. >From Jaeger@fquest.com (Brian Stern)
  838. Date: 22 Aug 1994 17:00:11 GMT
  839. Organization: The University of Texas at Austin, Austin, Texas
  840.  
  841. In article <9668AA7E6CA4.FDF19@klkmac008.nada.kth.se>, h+@nada.kth.se (Jon
  842. W{tte) wrote:
  843.  
  844. > A4 globals are much more horrible than comparing addresses of 
  845. > functions. A4 globals require you to always enter through 
  846. > main(), unless you do extra inline assembly, which kind of 
  847. > rules out the case where the loader and the patch are in the 
  848. > same code resource.
  849.  
  850. This isn't true.  With A4 globals you must enter through main *once*.  You
  851. save the address of A4 in main.  After that you can enter through any
  852. entry point you like.  Each additional entry point first retrieves A4 and
  853. can then access its globals.  It restores A4 before exiting.  There is no
  854. reason you can't have the loader and the patch in the same code resource.
  855.  
  856. > PS: you can get by the loader-left problem by putting the 
  857. > loader code last, branch to it from the top and then call 
  858. > SetHandleSize.
  859.  
  860. I agree that this is a neat trick.  Unfortunately you can't use it when
  861. using A4 global addressing.  The globals end up at the end of the code
  862. resource.  Oh well.
  863.  
  864. > --
  865. >   Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  866. >  "Don't Deal with a Dragon."
  867.  
  868. -- 
  869. Brian  Stern  :-{)}
  870. Jaeger@fquest.com
  871.  
  872. +++++++++++++++++++++++++++
  873.  
  874. >From h+@nada.kth.se (Jon W{tte)
  875. Date: Tue, 23 Aug 1994 08:54:14 +0200
  876. Organization: Royal Institute of Something or other
  877.  
  878. In article <Jaeger-2208941202170001@slip-2-18.ots.utexas.edu>,
  879. Jaeger@fquest.com (Brian Stern) wrote:
  880.  
  881. >This isn't true.  With A4 globals you must enter through main *once*.  You
  882. >save the address of A4 in main.  After that you can enter through any
  883. >entry point you like.  Each additional entry point first retrieves A4 and
  884. >can then access its globals.  It restores A4 before exiting.  There is no
  885. >reason you can't have the loader and the patch in the same code resource.
  886.  
  887. How do you retrieve the stored value of A4 without extra inline 
  888. assembly? Or does Symantec provide the extra assembler to do it 
  889. for you from anywhere now ?(it was a long time since I last used 
  890. it...)
  891.  
  892.  
  893. Cheers,
  894.  
  895.                 / h+
  896.  
  897.  
  898. --
  899.   Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  900.   "Psychotherapist" - "Phycho-The-Rapist"
  901.    Pure coincidence? You decide!
  902.  
  903.  
  904. +++++++++++++++++++++++++++
  905.  
  906. >From Jaeger@fquest.com (Brian Stern)
  907. Date: 23 Aug 1994 16:19:46 GMT
  908. Organization: The University of Texas at Austin, Austin, Texas
  909.  
  910. In article <9668AA7F69B6.206994@klkmac012.nada.kth.se>, h+@nada.kth.se
  911. (Jon W{tte) wrote:
  912.  
  913. > How do you retrieve the stored value of A4 without extra inline 
  914. > assembly? Or does Symantec provide the extra assembler to do it 
  915. > for you from anywhere now ?(it was a long time since I last used 
  916. > it...)
  917. > Cheers,
  918. >                                 / h+
  919. > --
  920. >   Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  921. >   "Psychotherapist" - "Phycho-The-Rapist"
  922. >    Pure coincidence? You decide!
  923.  
  924. Yes, the inline code is provided in a header file that must be included in
  925. each source file that needs to do A4 addressing.  The header contains
  926. several inline assembler functions for saving and restoring A4.  From the
  927. standpoint of the programmer there is no assembly required.
  928.  
  929. -- 
  930. Brian  Stern  :-{)}
  931. Jaeger@fquest.com
  932.  
  933. +++++++++++++++++++++++++++
  934.  
  935. >From phils@bedford.symantec.com (Phil Shapiro)
  936. Date: Tue, 23 Aug 1994 19:31:26 -0400
  937. Organization: Symantec Corp.
  938.  
  939. In article <9668AA7F69B6.206994@klkmac012.nada.kth.se>, h+@nada.kth.se
  940. (Jon W{tte) wrote:
  941.  
  942. | In article <Jaeger-2208941202170001@slip-2-18.ots.utexas.edu>,
  943. | Jaeger@fquest.com (Brian Stern) wrote:
  944. | >This isn't true.  With A4 globals you must enter through main *once*.  You
  945. | >save the address of A4 in main.  After that you can enter through any
  946. | >entry point you like.  Each additional entry point first retrieves A4 and
  947. | >can then access its globals.  It restores A4 before exiting.  There is no
  948. | >reason you can't have the loader and the patch in the same code resource.
  949. | How do you retrieve the stored value of A4 without extra inline 
  950. | assembly? Or does Symantec provide the extra assembler to do it 
  951. | for you from anywhere now ?(it was a long time since I last used 
  952. | it...)
  953.  
  954. Each source file gets its own copy of A4. As long as you're in the same
  955. source file that you called RememberA0() in (or RememberA4(), if A4 was
  956. valid already), you can call SetUpA4() at any entry point. This is because
  957. A4 is stored inside code in a static function; each file that uses the
  958. function gets a different copy. This has been true for quite awhile, I'm
  959. pretty sure that LSC 4.0 worked this way.
  960.  
  961. If you build with a custom header, you don't even need to enter main() at
  962. all. But you better set up A4 before you access any globals or
  963. cross-segment routines.
  964.  
  965.    -phil
  966.  
  967. ---------------------------
  968.  
  969. >From "Andrew C. Plotkin" <ap1i+@andrew.cmu.edu>
  970. Subject: Sound Manager headaches (again)
  971. Date: Sun, 21 Aug 1994 14:42:43 -0400
  972. Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA
  973.  
  974. When we last left our hero, he had just figured out how to play a sound
  975. at a given frequency (by sending soundCmd and freqDurationCmd to a
  976. sampledSynth channel.) (I sent a code snippet of doing this to
  977. alt.sources.mac, if you care. ./vol-08/sampledsnd.cpt.hqx)
  978.  
  979. Well, there was a reason I wanted to do that. See, I want to get music
  980. out, and I thought that the way to do that was record snd resources of
  981. each instrument, and then use that technique to play notes. Allocate
  982. several channels, you can get multiple notes at once.
  983.  
  984. ...Riiiiight.
  985.  
  986. First problem: they don't start off in synch. I use the algorithm given
  987. in the PlayTwoSoundsSynched in the SM3.0 tech note:  (warning:
  988. pseudocode, not real code, ahead)
  989.     SndDoImmediate(chan1, syncCmd{3, kID})
  990.     SndDoCommand(chan1, restCmd{500});
  991.     SndDoCommand(chan1, freqDurationCmd{500, MIDDLE_C});
  992.     SndDoImmediate(chan2, syncCmd{3, kID})
  993.     SndDoCommand(chan2, restCmd{500});
  994.     SndDoCommand(chan2, freqDurationCmd{500, MIDDLE_G});
  995.     SndDoImmediate(chan1, syncCmd{1, kID})
  996. I expect this to pause a quarter-second, then play a nice chord. Nope.
  997. One channel (the first one, I believe) starts slightly -- but audibly --
  998. first. (They do finish together, though.) This occurs both with and
  999. without SM3.0. 
  1000. (My guess: the SM has to resample one or both sounds to a different
  1001. frequency, and this takes some time. Sigh.) 
  1002. Oh, yeah -- syncCmd behaves with extreme magic. I still don't know
  1003. exactly what it does. For example, if I change the last line in the
  1004. algorithm above from chan1 to chan2, only one note plays instead of
  1005. both. Huh?
  1006.  
  1007. Second problem: Under SM3.0, if I play a sequence of notes of the same
  1008. duration, they don't come out with the same duration. Again, the
  1009. difference is pretty audible -- as much as a 50% error in short notes.
  1010. Unless I can do something about this, my entire plan is screwed. (Kinda
  1011. cool, huh? The nifty new SM *doesn't support freqDurationCmd* in a
  1012. usable form. I was pleased.) I recall someone else posted about this a
  1013. few weeks ago, and he couldn't get it to work either.
  1014. (My guess: same reason as before. The SM *does* keep the same
  1015. (distorted) time between channels; if I start two parallel synched
  1016. sequences, they stay synched. I guess that's something. It still ruins
  1017. the music, though.)
  1018.  
  1019. My question, pretty much, is "Have I missed anything?" I don't think I
  1020. have. I think I'm going to have to ditch the whole idea of
  1021. freqDurationCmd, and write my *own* sound-resampling-and-playing module
  1022. a la SoundTracker. (Or just use SoundTracker or some other MOD player.
  1023. This is tempting, but I haven't seen a freeware MOD player which
  1024. includes source code, except for an icky-looking one ported straight
  1025. from Unix, with malloc() everywhere. Anyone? Anyone?)
  1026.  
  1027. ObBribery: if you give me a magic answer that fixes my music-playing
  1028. code, I'll release the code as freeware. And I'll throw in the
  1029. simple-but-oh-so-elegant music editor I've spent the past month on.
  1030. (OTOH, if I wind up writing a MOD-style thing, I'll do the same thing.
  1031. Nevertheless.)
  1032.  
  1033. --Z
  1034.  
  1035. "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
  1036.  
  1037. +++++++++++++++++++++++++++
  1038.  
  1039. >From Rick_Holzgrafe@taligent.com (Rick Holzgrafe)
  1040. Date: Mon, 22 Aug 1994 18:22:58 GMT
  1041. Organization: Semicolon Software
  1042.  
  1043. In article <siJu0X_00gpI9iY0YJ@andrew.cmu.edu>, "Andrew C. Plotkin"
  1044. <ap1i+@andrew.cmu.edu> wrote:
  1045.  
  1046. > Second problem: Under SM3.0, if I play a sequence of notes of the same
  1047. > duration, they don't come out with the same duration. Again, the
  1048. > difference is pretty audible -- as much as a 50% error in short notes.
  1049. > Unless I can do something about this, my entire plan is screwed. (Kinda
  1050. > cool, huh? The nifty new SM *doesn't support freqDurationCmd* in a
  1051. > usable form. I was pleased.) I recall someone else posted about this a
  1052. > few weeks ago, and he couldn't get it to work either.
  1053.  
  1054. That was me, I think. I've heard The Word from The Source: a key
  1055. programmer at Apple tells me that SM 3.0 has been optimized for playing
  1056. sampled sounds. The optimizations DE-optimized for playing melodies via
  1057. freqDurationCmd; something about internal buffers having a size that
  1058. causes perceptible delays when they need to be refilled. There is no
  1059. workaround. For my app, I had to give up on freqDurationCmds (under SM
  1060. 3.0) and convert my tunes to single sampled sound resources, which
  1061. increased their size by two orders of magnitude and (to keep them from
  1062. getting even larger) decreased their sound quality. My app now tests the
  1063. version of the Sound Manager; if it is 3.0, you get one and only one
  1064. melody; if less than 3.0, you get a rotating selection out of a list of
  1065. seven melodies. The seven melodies take up about 20K of disk space; the
  1066. one sampled-sound melody takes several times that. Feh.
  1067.  
  1068. FWIW, I can show you code that should solve your synchronization problem.
  1069. Your various melodic parts will start together correctly, and they will
  1070. stay synched. Doesn't help the uneven tempo, though.
  1071.  
  1072. -- Rick Holzgrafe
  1073.    Semicolon Software
  1074.    rmh@taligent.com
  1075.  
  1076. +++++++++++++++++++++++++++
  1077.  
  1078. >From h+@nada.kth.se (Jon W{tte)
  1079. Date: Tue, 23 Aug 1994 09:49:07 +0200
  1080. Organization: Royal Institute of Something or other
  1081.  
  1082. In article <Rick_Holzgrafe-2208941123020001@ricks-cafe.taligent.com>,
  1083. Rick_Holzgrafe@taligent.com (Rick Holzgrafe) wrote:
  1084.  
  1085. >version of the Sound Manager; if it is 3.0, you get one and only one
  1086. >melody; if less than 3.0, you get a rotating selection out of a list of
  1087. >seven melodies. The seven melodies take up about 20K of disk space; the
  1088. >one sampled-sound melody takes several times that. Feh.
  1089.  
  1090. With QuickTime 2.0, however, all you do is store a General MIDI 
  1091. file in your resource fork (3-10k) and there's your melody.
  1092.  
  1093. Luckily, this isn't rec.music.makers.synth, where "General 
  1094. MIDI" is a cuss word.
  1095.  
  1096. Cheers,
  1097.  
  1098.                 / h+
  1099.  
  1100.  
  1101. --
  1102.   Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  1103.   "Psychotherapist" - "Phycho-The-Rapist"
  1104.    Pure coincidence? You decide!
  1105.  
  1106.  
  1107. +++++++++++++++++++++++++++
  1108.  
  1109. >From Rick_Holzgrafe@taligent.com (Rick Holzgrafe)
  1110. Date: Tue, 23 Aug 1994 18:24:34 GMT
  1111. Organization: Semicolon Software
  1112.  
  1113. In article <Rick_Holzgrafe-2208941123020001@ricks-cafe.taligent.com>,
  1114. Rick_Holzgrafe@taligent.com (Rick Holzgrafe) wrote:
  1115.  
  1116. >version of the Sound Manager; if it is 3.0, you get one and only one
  1117. >melody; if less than 3.0, you get a rotating selection out of a list of
  1118. >seven melodies. The seven melodies take up about 20K of disk space; the
  1119. >one sampled-sound melody takes several times that. Feh.
  1120.  
  1121. In article <9668AA7F7693.236F39@klkmac012.nada.kth.se>, h+@nada.kth.se
  1122. (Jon W{tte) wrote:
  1123.  
  1124. > With QuickTime 2.0, however, all you do is store a General MIDI 
  1125. > file in your resource fork (3-10k) and there's your melody.
  1126.  
  1127. Great. So now instead of checking for the version of the Sound Manager and
  1128. having two methods of playing music, I must also check for the presence
  1129. and version of QuickTime, and have THREE methods. Ain't progress
  1130. wonderful?
  1131.  
  1132. Your pardon, please, for my surliness. I'm just tired of carefully coding
  1133. to Apple's published interfaces, and having my sound code break anyway
  1134. every couple of years.
  1135.  
  1136. -- Rick Holzgrafe
  1137.    Semicolon Software
  1138.    rmh@taligent.com
  1139.  
  1140. ---------------------------
  1141.  
  1142. >From mdc14@ciao.cc.columbia.edu (Michael D Coble)
  1143. Subject: Stopping a 'snd ' resource dead
  1144. Date: 23 Aug 1994 03:53:01 GMT
  1145. Organization: Columbia University
  1146.  
  1147.         I am a programming student trying to write a couple of macintosh
  1148. applications.  I recorded some music into a 'snd ' resource and want to
  1149. invoke the music when a user chooses the about this application from the
  1150. apple menu accompanied by a little animation.  The 'snd ' resource is a
  1151. couple of minutes long, so I'd like to be able to allow a user to click
  1152. the close box and stop it in its tracks.  I wonder if one of you
  1153. experienced programmers out there might point me in the direction to
  1154. reach this goal.
  1155.  
  1156.                 Thanks,  Michael Coble, mdc14@columbia.edu
  1157.  
  1158.  
  1159. +++++++++++++++++++++++++++
  1160.  
  1161. >From bb@lightside.com (Bob Bradley)
  1162. Date: Sun, 21 Aug 1994 15:12:37 -0800
  1163. Organization: SS Software Inc.
  1164.  
  1165. In article <33brqt$mi8@apakabar.cc.columbia.edu>,
  1166. mdc14@ciao.cc.columbia.edu (Michael D Coble) wrote:
  1167.  
  1168. >         I am a programming student trying to write a couple of macintosh
  1169. > applications.  I recorded some music into a 'snd ' resource and want to
  1170. > invoke the music when a user chooses the about this application from the
  1171. > apple menu accompanied by a little animation.  The 'snd ' resource is a
  1172. > couple of minutes long, so I'd like to be able to allow a user to click
  1173. > the close box and stop it in its tracks.  I wonder if one of you
  1174. > experienced programmers out there might point me in the direction to
  1175. > reach this goal.
  1176.  
  1177. You can do this by playing the sound async. Something like this:
  1178.  
  1179. SndNewChannel(...)                  // Create a new sound channel
  1180. soundHandle = GetResource(...)      // Get the snd resource
  1181. SndPlay(...)                        // Play the sound setting async to true
  1182. SndDisposeChanne(...)               // Dispose of the sound channel and setting
  1183.                                     // quietNow to true so it stops any sound
  1184.                                     // that is currently playing.
  1185.  
  1186. Hope that helps and doesn't contain too many errors :)
  1187.  
  1188. +++++++++++++++++++++++++++
  1189.  
  1190. >From reed@medicine.wustl.edu (Thomas Reed)
  1191. Date: Tue, 23 Aug 1994 11:08:58 -0500
  1192. Organization: Washington University
  1193.  
  1194. If you ftp to thomas_mac.wustl.edu, you'll find the source code for a
  1195. solitaire game I wrote a while back.  It contains some very useful
  1196. libraries I've written -- one of which is a sound library.  Not only will
  1197. it let you do what you want to do, but it'll also let you play the sound
  1198. from disk to reduce the memory requirements.
  1199.  
  1200. Hope you like it!
  1201.  
  1202. Oh, for those of you with NewsWatcher, here's the URL:
  1203.  
  1204.   ftp://thomas_mac.wustl.edu/Public/for_ftp/Solitaire_code.sit
  1205.  
  1206. -Thomas
  1207.  
  1208. =====================================================
  1209. Thomas Reed                     Washington University
  1210. reed@telesphere.wustl.edu           Medical School
  1211. reed@medicine.wustl.edu            Saint Louis, MO
  1212. - ---------------------------------------------------
  1213. Clothes make the man.  Naked people have little or no
  1214. influence on society.  -- Mark Twain
  1215. =====================================================
  1216.  
  1217. Opinions posted are not the opinions of Wash. U.
  1218.  
  1219. ---------------------------
  1220.  
  1221. >From chris-b@cs.auckland.ac.nz (Chris Burns)
  1222. Subject: [Q] What does "_Xxxxx ,Sys,Immed" mean?
  1223. Date: Wed, 24 Aug 1994 11:36:07 +1200
  1224. Organization: AucklandUniversity:ComputerScience:HMU
  1225.  
  1226. Hi all,
  1227.  
  1228. What do the ",Sys,Immed" qualifiers mean?
  1229. I know they specify certain bits in the trap word, but what do the
  1230. different combinations mean?
  1231.  
  1232. What I want is a table:
  1233.  
  1234. Sys   Immed    Meaning
  1235.  
  1236.  x      x      ?
  1237.  x             ?
  1238.         x      ?
  1239.                ?
  1240.  
  1241. Thanks Heaps In Advance,
  1242.  
  1243. Chris B
  1244. - ---------------------------------------------------------------------
  1245. NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
  1246. Internet: chris-b@cs.auckland.ac.nz
  1247. Phone:    +64 9 373-7599 x6194
  1248. Fax:      +64 9 373-7453                         Async, therefore I am.
  1249. - ---------------------------------------------------------------------
  1250.  
  1251. +++++++++++++++++++++++++++
  1252.  
  1253. >From wysocki@netcom.com (Chris Wysocki)
  1254. Date: Wed, 24 Aug 1994 15:27:25 GMT
  1255. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  1256.  
  1257. In article <chris-b-2408941136070001@hmu7.cs.aukuni.ac.nz>,
  1258. Chris Burns <chris-b@cs.auckland.ac.nz> wrote:
  1259.  
  1260. >What do the ",Sys,Immed" qualifiers mean?
  1261. >I know they specify certain bits in the trap word, but what do the
  1262. >different combinations mean?
  1263.  
  1264. The ",Sys" and ",Immed" qualifiers displayed by MacsBug can be
  1265. misnomers, since these are only two of the possible meaning of bits 9
  1266. and 10 of a trap word.  All the possible meaning for these bits can be
  1267. found in Traps.a:
  1268.  
  1269. ; Equates for setting trap option bits
  1270.  
  1271. ; for Device and File Manager routines
  1272.  
  1273. immed        EQU        $200      ; execute immediately, bypass I/O queue
  1274. async        EQU        $400      ; asynchronous, don't wait for completion
  1275.  
  1276. ; for Memory Manager routines
  1277.  
  1278. clear        EQU        $200
  1279. sys          EQU        $400
  1280.  
  1281. ; for string routines
  1282.  
  1283. marks        EQU        $200      ; set to ignore/strip diacriticals
  1284. case         EQU        $400      ; set for case sensitivity
  1285.  
  1286. ; for all Toolbox routines
  1287.  
  1288. autoPop      EQU        $400      ; set to pop an extra return address
  1289.  
  1290. ; for Get/Set & NGet/NSet TrapAddress
  1291.  
  1292. newTool      EQU        $600      ; Toolbox trap, under new ordering
  1293. newOS        EQU        $200      ; OS trap, under new ordering
  1294.  
  1295. ; for HFS routines
  1296.  
  1297. newHFS       EQU        $200
  1298.  
  1299.  
  1300. Chris.
  1301.  
  1302. ---------------------------
  1303.  
  1304. >From chrism@col.hp.com (Chris Magnuson)
  1305. Subject: jGNE from an INIT
  1306. Date: 17 Aug 1994 05:50:18 GMT
  1307. Organization: HP Colorado Springs Division
  1308.  
  1309.   I am writing a jGNE event filter in MPW that needs to be part of an INIT that
  1310.   does alot of other things ( i.e. the jGNE function is one part of the
  1311.   INIT code resource).  I've gotten alot done, but run into problems when
  1312.   events actually call my jGNE routine to do the event "interception/
  1313.   redirection."  
  1314.  
  1315.   short JGNEFilterFunc(short hasEvent, const EventRecord *theEvent)
  1316.  
  1317.   My question is this:  when the JGNEFilterFunc routine is called with an
  1318.   EventRecord, etc. am I supposed to be doing some A5 world swapping to
  1319.   get things to be handled properly in the jGNE routine?  Without posting
  1320.   alot of code here is basically what the INIT initialization does.  Hints
  1321.   are greatly appreciated!
  1322.  
  1323.  
  1324.   main() {
  1325.         oldZone = GetZone();
  1326.     SetZone(SystemZone());
  1327.  
  1328.     MakeA5World(&A5Ref);
  1329.     if (A5Ref == nil) {
  1330.         SetZone(oldZone);
  1331.         return(memFullErr);
  1332.     }
  1333.     a_SetA5Ref(A5Ref);
  1334.     oldA5 = SetA5World(A5Ref);
  1335.  
  1336.     (void) ReadPrefs();
  1337.     jGNEInit();    /* point to assembly glue routine that eventually calls
  1338.                         * JGNEFilterFunc() when events go through jGNE 0x29A
  1339.                         */
  1340.  
  1341.     (void) SetA5(oldA5);
  1342.     SetZone(oldZone);
  1343.    }
  1344.  
  1345. Chris Magnuson
  1346. chrism@col.hp.com
  1347.  
  1348. +++++++++++++++++++++++++++
  1349.  
  1350. >From gurgle@dnai.com (Pete Gontier)
  1351. Date: Tue, 16 Aug 1994 23:10:27 -0800
  1352. Organization: Integer Poet Software
  1353.  
  1354. In article <32s8eq$kdr@hp-col.col.hp.com>,
  1355. chrism@col.hp.com (Chris Magnuson) wrote:
  1356.  
  1357. > I am writing a jGNE event filter in MPW that needs to be part of an INIT...
  1358. > am I supposed to be doing some A5 world swapping... ?
  1359.  
  1360. You will want to read the DSC Technical Note "Stand-alone Code Resources
  1361. Ad Nauseum" if you have not already. The short answer is yes, you do need
  1362. to do some twiddling to get access to global variables.
  1363.  
  1364. Frankly, though, I would recommend doing this project in THINK C, because
  1365. (a) assembly code is easier to integrate, (b) global variables are easier
  1366. to access, and (c) my sample jGNE INIT, "jGNE Helper", is posted monthly
  1367. to 'alt.sources.mac' with a THINK C project and will make all of these
  1368. problems go away for you.
  1369.  
  1370. -- 
  1371.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  1372.  
  1373.  "I am Homer of Borg! Prepare to be... Ooooooo! Donuts!"
  1374.  
  1375. +++++++++++++++++++++++++++
  1376.  
  1377. >From neil_ticktin@xplain.com (Neil Ticktin)
  1378. Date: Wed, 17 Aug 1994 16:26:42 GMT
  1379. Organization: MacTech Magazine/Xplain Corporation
  1380.  
  1381. In article <32s8eq$kdr@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1382. Magnuson) wrote:
  1383.  
  1384. >>   I am writing a jGNE event filter in MPW that needs to be part of an
  1385. INIT that
  1386. >>   does alot of other things ( i.e. the jGNE function is one part of the
  1387. >>   INIT code resource).  I've gotten alot done, but run into problems when
  1388. >>   events actually call my jGNE routine to do the event "interception/
  1389. >>   redirection."  
  1390. >> 
  1391.  
  1392. Chris,
  1393.  
  1394. Late last year, there was a great article by Symantec Tech Support in
  1395. about writing a jGNEFilter.  It was one of the THINK Top 10 columns.  It
  1396. contained the template code and an example of how to do it.  I'm on the
  1397. road and don't have the issue handy, but you should check it out.
  1398.  
  1399. Hope it helps,
  1400.  
  1401. Neil
  1402.  
  1403. - ---------------------------------------------------------------------
  1404.            Neil Ticktin, MacTech Magazine (formerly MacTutor)
  1405. PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925
  1406.  For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  1407.   custservice@xplain.com * editorial@xplain.com * adsales@xplain.com
  1408. marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com
  1409.    progchallenge@xplain.com * publisher@xplain.com * info@xplain.com
  1410.  
  1411. +++++++++++++++++++++++++++
  1412.  
  1413. >From chrism@col.hp.com (Chris Magnuson)
  1414. Date: 17 Aug 1994 20:14:57 GMT
  1415. Organization: HP Colorado Springs Division
  1416.  
  1417. Pete Gontier (gurgle@dnai.com) wrote:
  1418. : In article <32s8eq$kdr@hp-col.col.hp.com>,
  1419. : chrism@col.hp.com (Chris Magnuson) wrote:
  1420.  
  1421. : > I am writing a jGNE event filter in MPW that needs to be part of an INIT...
  1422. : > am I supposed to be doing some A5 world swapping... ?
  1423.  
  1424. : You will want to read the DSC Technical Note "Stand-alone Code Resources
  1425. : Ad Nauseum" if you have not already. The short answer is yes, you do need
  1426. : to do some twiddling to get access to global variables.
  1427.  
  1428. : Frankly, though, I would recommend doing this project in THINK C, because
  1429. : (a) assembly code is easier to integrate, (b) global variables are easier
  1430. : to access, and (c) my sample jGNE INIT, "jGNE Helper", is posted monthly
  1431. : to 'alt.sources.mac' with a THINK C project and will make all of these
  1432. : problems go away for you.
  1433.  
  1434.  
  1435.  No it won't :)  I must not be communicating what has to happen here.  main()
  1436.  is no longer the entry point for a jGNE filter only.  main() is the entry
  1437.  point for an entire INIT, one component of which is a jGNE event processor.
  1438.  So the code resource in question here is an entire INIT, not just a jGNE
  1439.  filter.
  1440.  
  1441.  In other words, the jGNE portion of the code is one routine within the INIT
  1442.  code resource, and I have glue that dispatches to that routine, but it
  1443.  does not behave properly.
  1444.  
  1445.  So maybe the question is, when the jGNE event is dispatched to the code
  1446.  within my INIT, must I set A5 for some reason?  Even though I am not
  1447.  interested in globals (just the parameters on the stack)?
  1448.  
  1449.  Chris Magnuson
  1450.  chrism@col.hp.com
  1451.  
  1452. +++++++++++++++++++++++++++
  1453.  
  1454. >From chrism@col.hp.com (Chris Magnuson)
  1455. Date: 17 Aug 1994 20:16:09 GMT
  1456. Organization: HP Colorado Springs Division
  1457.  
  1458.   Thanks.  Yes, I did check that out.  It doesnt answer my question since it
  1459.   is a standalone jGNE (in other words the jGNE event processor is not part
  1460.   of a larger code resource with other things going on).
  1461.  
  1462. Chris Magnuson
  1463. chrism@col.hp.com
  1464.  
  1465.  
  1466. Neil Ticktin (neil_ticktin@xplain.com) wrote:
  1467. : In article <32s8eq$kdr@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1468. : Magnuson) wrote:
  1469.  
  1470. : >>   I am writing a jGNE event filter in MPW that needs to be part of an
  1471. : INIT that
  1472. : >>   does alot of other things ( i.e. the jGNE function is one part of the
  1473. : >>   INIT code resource).  I've gotten alot done, but run into problems when
  1474. : >>   events actually call my jGNE routine to do the event "interception/
  1475. : >>   redirection."  
  1476. : >> 
  1477.  
  1478. : Chris,
  1479.  
  1480. : Late last year, there was a great article by Symantec Tech Support in
  1481. : about writing a jGNEFilter.  It was one of the THINK Top 10 columns.  It
  1482. : contained the template code and an example of how to do it.  I'm on the
  1483. : road and don't have the issue handy, but you should check it out.
  1484.  
  1485. : Hope it helps,
  1486.  
  1487. : Neil
  1488.  
  1489. : -----------------------------------------------------------------------
  1490. :            Neil Ticktin, MacTech Magazine (formerly MacTutor)
  1491. : PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925
  1492. :  For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  1493. :   custservice@xplain.com * editorial@xplain.com * adsales@xplain.com
  1494. : marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com
  1495. :    progchallenge@xplain.com * publisher@xplain.com * info@xplain.com
  1496.  
  1497. +++++++++++++++++++++++++++
  1498.  
  1499. >From larson@oahu.cs.ucla.edu (Christopher Larson)
  1500. Date: Wed, 17 Aug 94 21:28:50 GMT
  1501. Organization: UCLA, Computer Science Department
  1502.  
  1503. In article <32tr42$pfg@hp-col.col.hp.com> chrism@col.hp.com (Chris Magnuson) writes:
  1504. >: In article <32s8eq$kdr@hp-col.col.hp.com>,
  1505. >: chrism@col.hp.com (Chris Magnuson) wrote:
  1506. >
  1507. >: > I am writing a jGNE event filter in MPW that needs to be part of an INIT...
  1508. >: > am I supposed to be doing some A5 world swapping... ?
  1509.  
  1510. [...]
  1511.  
  1512. > So maybe the question is, when the jGNE event is dispatched to the code
  1513. > within my INIT, must I set A5 for some reason?  Even though I am not
  1514. > interested in globals (just the parameters on the stack)?
  1515.  
  1516. If you don't use (or cause to be used) any globals, you don't need an A5
  1517. world, and, therefore, you don't need to set A5.
  1518.  
  1519. If the jGNE filter doesn't need access to any globals, why is it part of
  1520. the INIT (I read the above to mean the jGNE code is within the INIT resource,
  1521. if not, ignore this)? Wouldn't it be easier to compile the jGNE portion as
  1522. a seperate resource, and just load, detatch, and install from the INIT
  1523. resource?
  1524.  
  1525. --Chris <Wondering if he's missing something obvious> Larson
  1526. _______________________________________________________________________________
  1527. Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
  1528. L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
  1529. Death to the Trojans! Go Bruins!
  1530.  
  1531. (Insert disclaimer here)
  1532. Internet: larson@kingston.cs.ucla.edu
  1533.  
  1534. +++++++++++++++++++++++++++
  1535.  
  1536. >From Jaeger@fquest.com (Brian Stern)
  1537. Date: 18 Aug 1994 00:53:36 GMT
  1538. Organization: The University of Texas at Austin, Austin, Texas
  1539.  
  1540. In article <32tr42$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1541. Magnuson) wrote:
  1542.  
  1543. > Pete Gontier (gurgle@dnai.com) wrote:
  1544. > : In article <32s8eq$kdr@hp-col.col.hp.com>,
  1545. > : chrism@col.hp.com (Chris Magnuson) wrote:
  1546. > : > I am writing a jGNE event filter in MPW that needs to be part of an
  1547. INIT...
  1548. > : > am I supposed to be doing some A5 world swapping... ?
  1549.  
  1550. >  No it won't :)  I must not be communicating what has to happen here.  main()
  1551. >  is no longer the entry point for a jGNE filter only.  main() is the entry
  1552. >  point for an entire INIT, one component of which is a jGNE event processor.
  1553. >  So the code resource in question here is an entire INIT, not just a jGNE
  1554. >  filter.
  1555. >  In other words, the jGNE portion of the code is one routine within the INIT
  1556. >  code resource, and I have glue that dispatches to that routine, but it
  1557. >  does not behave properly.
  1558. >  So maybe the question is, when the jGNE event is dispatched to the code
  1559. >  within my INIT, must I set A5 for some reason?  Even though I am not
  1560. >  interested in globals (just the parameters on the stack)?
  1561. >  Chris Magnuson
  1562. >  chrism@col.hp.com
  1563.  
  1564. In order to function properly any jGNEFilter has to insert itself into the
  1565. chain of all jGNEFilters.  When your filter exits it needs to jump to the
  1566. previous filter.  The address of the previous filter must be saved at the
  1567. time that you install your filter.  This saved address must be a global. 
  1568. Therefore your jGNEFilter, and all jGNEFilters for all time, must have
  1569. access to global variables.  There are several mechanisms for accessing
  1570. global variables in stand alone code resources like your jGNEFilter.  As I
  1571. understand it MPW uses an A5-based mechanism that is described in the tech
  1572. note.  Use that mechanism if you like.  Think, and I believe CW, use an
  1573. A4-based mechanism, which is straightforward to use.  Aside from access to
  1574. the previous filter's address or to other global variables there is no
  1575. requirement for an A5 world to be set up.
  1576.  
  1577. There is a sample jGNEFilter written by Dave Falkenberg that can be found
  1578. at ftp.apple.com.  This sample is all in MPW assembler.  It does not use
  1579. the A5 mechanism for storing the address of the previous filter.  It
  1580. simply stores the address within itself.
  1581.  
  1582. -- 
  1583. Brian  Stern  :-{)}
  1584. Jaeger@fquest.com
  1585.  
  1586. +++++++++++++++++++++++++++
  1587.  
  1588. >From gurgle@dnai.com (Pete Gontier)
  1589. Date: Wed, 17 Aug 1994 21:17:15 -0800
  1590. Organization: Integer Poet Software
  1591.  
  1592. In article <1994Aug17.212850.10867@cs.ucla.edu>, larson@oahu.cs.ucla.edu
  1593. (Christopher Larson) wrote:
  1594.  
  1595. > If the jGNE filter doesn't need access to any globals, why is it part of
  1596. > the INIT ... ? Wouldn't it be easier to compile the jGNE portion as
  1597. > a seperate resource, and just load, detatch, and install from the INIT
  1598. > resource?
  1599.  
  1600. His filter might want to call other functions in the INIT without
  1601. duplicating them in the jGNE resource. I don't know enough about
  1602. MPW-generated code resources to be able to say whether it needs A5 to call
  1603. functions. Probably it uses PC-relative calls, but it's something you
  1604. would want to look up.
  1605.  
  1606. -- 
  1607.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  1608.  
  1609.  "Even during a particularly harsh (Colorado) winter... many of the
  1610.  300 families in the VCTV (movies-on-demand) trial continued to go
  1611.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  1612.  
  1613. +++++++++++++++++++++++++++
  1614.  
  1615. >From gurgle@dnai.com (Pete Gontier)
  1616. Date: Wed, 17 Aug 1994 21:25:33 -0800
  1617. Organization: Integer Poet Software
  1618.  
  1619. In article <32tr42$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1620. Magnuson) wrote:
  1621.  
  1622. >  I must not be communicating what has to happen here.  main()
  1623. >  is no longer the entry point for a jGNE filter only.  main() is the entry
  1624. >  point for an entire INIT, one component of which is a jGNE event processor.
  1625. >  So the code resource in question here is an entire INIT, not just a jGNE
  1626. >  filter. In other words, the jGNE portion of the code is one routine within
  1627. >  the INIT code resource, and I have glue that dispatches to that routine,
  1628. >  but it does not behave properly.
  1629.  
  1630. As I said in email, I know. :-) Probably I am the one who did insufficient
  1631. communicating. With a THINK (or CodeWarrior) compiler, what you're asking
  1632. about is trivial, because the compiler actually knows that it's compiling
  1633. something other than an application, unlike MPW. MPW only knows at link
  1634. time; consequently, MPW code resource have to pretend in many ways that
  1635. they are apps. Hence that entire tech note about code resources and A5.
  1636. Blech.
  1637.  
  1638. >  So maybe the question is, when the jGNE event is dispatched to the code
  1639. >  within my INIT, must I set A5 for some reason?  Even though I am not
  1640. >  interested in globals (just the parameters on the stack)?
  1641.  
  1642. Again as I said in email, if your code does not use statically allocated
  1643. variables (locals declared 'static' or globals), you may still need to set
  1644. up A5 if your filter calls other routines, depending on how MPW finds
  1645. those routines. Probably it finds them PC-relative, but it may find them
  1646. A5-relative. Perhaps some MPW guru can shed light on this.
  1647.  
  1648. -- 
  1649.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  1650.  
  1651.  "Even during a particularly harsh (Colorado) winter... many of the
  1652.  300 families in the VCTV (movies-on-demand) trial continued to go
  1653.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  1654.  
  1655. +++++++++++++++++++++++++++
  1656.  
  1657. >From Jaeger@fquest.com (Brian Stern)
  1658. Date: 19 Aug 1994 02:36:45 GMT
  1659. Organization: The University of Texas at Austin, Austin, Texas
  1660.  
  1661. In article <jedavis.777254033@Xenon.Stanford.EDU>,
  1662. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  1663.  
  1664. > On a side note.. I dont suppose you have any idea if I can 
  1665. > allocate some memory in a jGNEfilter? I dont mind stealing
  1666. > from the host app. I want to muck with the clipboard, so need 
  1667. > a couple handles that dont mind being resized by the Scrap calls.
  1668. > -James
  1669.  
  1670. Since jGNEFilters are called from WNE/GNE and both of those traps are
  1671. documented as moving or purging memory, Yes you can allocate memory from
  1672. inside a jGNEFilter.  If you want the memory to last longer than one pass
  1673. through your filter make sure to allocate the memory in the system heap,
  1674. otherwise it will be lost if the app quits.  If the memory will be
  1675. allocated and disposed within one pass of the filter it can go in the
  1676. application's heap.
  1677.  
  1678. -- 
  1679. Brian  Stern  :-{)}
  1680. Jaeger@fquest.com
  1681.  
  1682. +++++++++++++++++++++++++++
  1683.  
  1684. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  1685. Date: 18 Aug 94 18:51:13 GMT
  1686. Organization: Stanford University: Computer Science Department
  1687.  
  1688. larson@oahu.cs.ucla.edu (Christopher Larson) writes:
  1689.  
  1690. >In article <32tr42$pfg@hp-col.col.hp.com> chrism@col.hp.com (Chris Magnuson) writes:
  1691. >> So maybe the question is, when the jGNE event is dispatched to the code
  1692. >> within my INIT, must I set A5 for some reason?  Even though I am not
  1693. >> interested in globals (just the parameters on the stack)?
  1694.  
  1695. >If you don't use (or cause to be used) any globals, you don't need an A5
  1696. >world, and, therefore, you don't need to set A5.
  1697.  
  1698. Yes, but remember that some Quickdraw globals are offset from A5 as
  1699. well. You might not need *your* A5, but you will need a valid one.
  1700. I bring this up, because inside your jGNEfilter you wont
  1701. neccessarily get one. You can set the A5 of the
  1702. currently executing application from the low memory global CurrentA5,
  1703. but remember to put back whatever stuffs was in A5 to start with.
  1704.  
  1705. James Davis : jedavis@cs.stanford.edu
  1706.  
  1707. +++++++++++++++++++++++++++
  1708.  
  1709. >From larson@oahu.cs.ucla.edu (Christopher Larson)
  1710. Date: Thu, 18 Aug 94 21:05:17 GMT
  1711. Organization: UCLA, Computer Science Department
  1712.  
  1713. James said:
  1714. >I said:
  1715. >>Chris Magnuson said:
  1716. >>> So maybe the question is, when the jGNE event is dispatched to the code
  1717. >>> within my INIT, must I set A5 for some reason?  Even though I am not
  1718. >>> interested in globals (just the parameters on the stack)?
  1719. >
  1720. >>If you don't use (or cause to be used) any globals, you don't need an A5
  1721. >>world, and, therefore, you don't need to set A5.
  1722. >
  1723. >Yes, but remember that some Quickdraw globals are offset from A5 as
  1724. >well.
  1725.  
  1726. Making any calls which require Quickdraw globals count as causing globals
  1727. to be used. (Perhaps I should have made that point clear :-).
  1728.  
  1729. > You might not need *your* A5, but you will need a valid one.
  1730.  
  1731. Why? If I don't use Quickdraw or my own globals, I shouldn't (see caveat
  1732. below) need an A5 world and shouldn't care what the value of A5 is. I've
  1733. written numerous code resources and trap patches (though never a jGNE
  1734. filter). I've never needed an A5 world of my own (meaning belonging to
  1735. the code resource), and only needed to borrow the current application's
  1736. A5 when using Quickdraw globals. Unless jGNE filters are inherently
  1737. different, I don't see why one must run with a valid A5. (I didn't
  1738. intend this to sound at all like a flame. I'm just trying to get to
  1739. the bottom of this too.)
  1740.  
  1741. caveat: As Peter Lewis pointed out, calls to other routines within
  1742. code resources may use a jump table, which may use A5. Consult your
  1743. development system regarding this. (I'm paraphrasing, excuse me if I've
  1744. misinterpreted you, Peter.)
  1745.  
  1746. >I bring this up, because inside your jGNEfilter you wont neccessarily get
  1747. >one.
  1748.  
  1749. You sure won't.
  1750.  
  1751. >You can set the A5 of the currently executing application from the low
  1752. >memory global CurrentA5, but remember to put back whatever stuffs was in
  1753. >A5 to start with.
  1754.  
  1755. An invaluable piece of information. Saved my hiney many times.
  1756.  
  1757. --Chris
  1758. _______________________________________________________________________________
  1759. Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
  1760. L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
  1761. Death to the Trojans! Go Bruins!
  1762.  
  1763. (Insert disclaimer here)
  1764. Internet: larson@kingston.cs.ucla.edu
  1765.  
  1766. +++++++++++++++++++++++++++
  1767.  
  1768. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  1769. Date: 18 Aug 94 23:53:53 GMT
  1770. Organization: Stanford University: Computer Science Department
  1771.  
  1772. larson@oahu.cs.ucla.edu (Christopher Larson) writes:
  1773.  
  1774. >> You might not need *your* A5, but you will need a valid one.
  1775. >Why? If I don't use Quickdraw or my own globals, I shouldn't (see caveat
  1776. >below) need an A5 world and shouldn't care what the value of A5 is. I've
  1777. >written numerous code resources and trap patches (though never a jGNE
  1778. >filter). I've never needed an A5 world of my own (meaning belonging to
  1779. >the code resource), and only needed to borrow the current application's
  1780. >A5 when using Quickdraw globals. Unless jGNE filters are inherently
  1781. >different, I don't see why one must run with a valid A5. (I didn't
  1782. >intend this to sound at all like a flame. I'm just trying to get to
  1783. >the bottom of this too.)
  1784.  
  1785. You're correct. I phrased something badly. I had meant to
  1786. suggest that stealing the current applications A5 would do
  1787. for quickdraw globals, if you didnt have one of your own handy.
  1788.  
  1789. On a side note.. I dont suppose you have any idea if I can 
  1790. allocate some memory in a jGNEfilter? I dont mind stealing
  1791. from the host app. I want to muck with the clipboard, so need 
  1792. a couple handles that dont mind being resized by the Scrap calls.
  1793.  
  1794. -James
  1795.  
  1796. +++++++++++++++++++++++++++
  1797.  
  1798. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  1799. Date: 19 Aug 94 09:42:08 GMT
  1800. Organization: Stanford University: Computer Science Department
  1801.  
  1802. Jaeger@fquest.com (Brian Stern) writes:
  1803.  
  1804. >In article <32tr42$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1805. >Magnuson) wrote:
  1806.  
  1807. >> Pete Gontier (gurgle@dnai.com) wrote:
  1808. >> : In article <32s8eq$kdr@hp-col.col.hp.com>,
  1809. >> : chrism@col.hp.com (Chris Magnuson) wrote:
  1810. >> 
  1811. >>  So maybe the question is, when the jGNE event is dispatched to the code
  1812. >>  within my INIT, must I set A5 for some reason?  Even though I am not
  1813. >>  interested in globals (just the parameters on the stack)?
  1814. >> 
  1815. >>  chrism@col.hp.com
  1816.  
  1817. >In order to function properly any jGNEFilter has to insert itself into the
  1818. >chain of all jGNEFilters.  When your filter exits it needs to jump to the
  1819. >previous filter.  The address of the previous filter must be saved at the
  1820. >time that you install your filter.  This saved address must be a global. 
  1821.  
  1822. Global? Well not really. Its not really good style, but Ive seen it done
  1823. by stuffing the address into your code at install time. The same way
  1824. many people store their app A5, with code that self modifies to
  1825. contain the location.
  1826. For that matter, where should I store my apps A5, so I can reset
  1827. it without using self modifying code?
  1828.  
  1829. -James 
  1830.  
  1831. +++++++++++++++++++++++++++
  1832.  
  1833. >From larson@oahu.cs.ucla.edu (Christopher Larson)
  1834. Date: Fri, 19 Aug 94 16:15:35 GMT
  1835. Organization: UCLA, Computer Science Department
  1836.  
  1837. In article <jedavis.777289328@Xenon.Stanford.EDU> jedavis@Xenon.Stanford.EDU (James Edward Davis) writes:
  1838. >Jaeger@fquest.com (Brian Stern) writes:
  1839. >>In order to function properly any jGNEFilter has to insert itself into the
  1840. >>chain of all jGNEFilters.  When your filter exits it needs to jump to the
  1841. >>previous filter.  The address of the previous filter must be saved at the
  1842. >>time that you install your filter.  This saved address must be a global. 
  1843. >
  1844. >Global? Well not really. Its not really good style, but Ive seen it done
  1845. >by stuffing the address into your code at install time. The same way
  1846. >many people store their app A5, with code that self modifies to
  1847. >contain the location.
  1848.  
  1849. I'm not sure this strategy counts as self-modification if the installed
  1850. code is contained in its own resource. When the app (INIT, whatever) loads
  1851. the resource, before detaching and installing, it's just data. If it's
  1852. modified at this point, I don't think you will have any problems (still
  1853. need to flush caches though), because the resource has never been loaded
  1854. as code. If the code to be installed is in your 'CODE' resources, all
  1855. bets are off. (Comments on this welcome....)
  1856.  
  1857. >For that matter, where should I store my apps A5, so I can reset
  1858. >it without using self modifying code?
  1859.  
  1860. Well, you could use the above strategy, or if that is still to self-modify-
  1861. ish, you could install a Gestalt selector. Note that trickery to recover your
  1862. A5 is only necessary if your code might run when your app is switched out or
  1863. at interrupt time. If this is not the case, you can recover it from CurrentA5,
  1864. as you suggested earlier. 
  1865.  
  1866. Hmmm. This raises an interesting question. If an app installs a jGNEFilter,
  1867. is that filter visible to all other applications, or is it more like trap
  1868. patches (which, if done from an app, are only visible to the installing app)?
  1869. Anyone?
  1870.  
  1871. Since this thread is about jGNEFilters, I assume your question was specific
  1872. to recovering A5 from a jGNEFilter/trap patch kind of situation. If not, mail
  1873. me with the specifics.
  1874.  
  1875. --Chris
  1876. _______________________________________________________________________________
  1877. Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
  1878. L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
  1879. Death to the Trojans! Go Bruins!
  1880.  
  1881. (Insert disclaimer here)
  1882. Internet: larson@kingston.cs.ucla.edu
  1883.  
  1884. +++++++++++++++++++++++++++
  1885.  
  1886. >From larson@oahu.cs.ucla.edu (Christopher Larson)
  1887. Date: Fri, 19 Aug 94 16:22:01 GMT
  1888. Organization: UCLA, Computer Science Department
  1889.  
  1890. In article <Jaeger-1808942138440001@slip-15-7.ots.utexas.edu> Jaeger@fquest.com (Brian Stern) writes:
  1891. >In article <jedavis.777254033@Xenon.Stanford.EDU>,
  1892. >jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  1893. >
  1894. >> On a side note.. I dont suppose you have any idea if I can 
  1895. >> allocate some memory in a jGNEfilter? I dont mind stealing
  1896. >
  1897. >Since jGNEFilters are called from WNE/GNE and both of those traps are
  1898. >documented as moving or purging memory, Yes you can allocate memory from
  1899. >inside a jGNEFilter.  If you want the memory to last longer than one pass
  1900. >through your filter make sure to allocate the memory in the system heap,
  1901. >otherwise it will be lost if the app quits.
  1902.  
  1903. Or, you could receive consecutive calls from two different applications.
  1904. Best, in any case, to allocate from the system heap if you want persistance.
  1905.  
  1906. >If the memory will be allocated and disposed within one pass of the filter
  1907. >it can go in the application's heap.
  1908.  
  1909. Or maybe temporary memory if you don't want to use the app's heap.
  1910.  
  1911. --Chris
  1912. _______________________________________________________________________________
  1913. Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
  1914. L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
  1915. Death to the Trojans! Go Bruins!
  1916.  
  1917. (Insert disclaimer here)
  1918. Internet: larson@kingston.cs.ucla.edu
  1919.  
  1920. +++++++++++++++++++++++++++
  1921.  
  1922. >From gurgle@dnai.com (Pete Gontier)
  1923. Date: Fri, 19 Aug 1994 09:45:18 -0800
  1924. Organization: Integer Poet Software
  1925.  
  1926. In article <1994Aug19.161535.10734@cs.ucla.edu>, larson@oahu.cs.ucla.edu
  1927. (Christopher Larson) wrote:
  1928.  
  1929. > If an app installs a jGNEFilter,
  1930. > is that filter visible to all other applications, or is it more like trap
  1931. > patches (which, if done from an app, are only visible to the installing app)?
  1932.  
  1933. It's visible to all other applications.
  1934.  
  1935. -- 
  1936.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  1937.  
  1938.  "Even during a particularly harsh (Colorado) winter... many of the
  1939.  300 families in the VCTV (movies-on-demand) trial continued to go
  1940.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  1941.  
  1942. +++++++++++++++++++++++++++
  1943.  
  1944. >From Jaeger@fquest.com (Brian Stern)
  1945. Date: 19 Aug 1994 16:43:20 GMT
  1946. Organization: The University of Texas at Austin, Austin, Texas
  1947.  
  1948. In article <jedavis.777289328@Xenon.Stanford.EDU>,
  1949. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  1950.  
  1951. > Jaeger@fquest.com (Brian Stern) writes:
  1952. > >In order to function properly any jGNEFilter has to insert itself into the
  1953. > >chain of all jGNEFilters.  When your filter exits it needs to jump to the
  1954. > >previous filter.  The address of the previous filter must be saved at the
  1955. > >time that you install your filter.  This saved address must be a global. 
  1956. > Global? Well not really. Its not really good style, but Ive seen it done
  1957. > by stuffing the address into your code at install time. The same way
  1958. > many people store their app A5, with code that self modifies to
  1959. > contain the location.
  1960. > For that matter, where should I store my apps A5, so I can reset
  1961. > it without using self modifying code?
  1962. > -James 
  1963.  
  1964. App?  I thought we were talking about about an INIT.  Installing a
  1965. jGNEFilter from an app has a number of problems to worry about.  I would
  1966. probably write the filter as a code resource using A4 addressing.  To
  1967. install it I'd load the resource into the system heap, set up A0, and jump
  1968. to it from the app to initilize it.  It would save A5 for later use.  It
  1969. would also have to make sure that the app still existed.  The A4 mechanism
  1970. as used by Think C is also a self-modifying mechanism and I don't see any
  1971. clean way around it.
  1972.  
  1973. Having said that, I recently came across some code in a package called
  1974. Extension Shell by Dair Grant that uses A4 addressing without being
  1975. self-modifying.  Here's the code:
  1976.  
  1977.    WRITTEN BY:
  1978.       Eric Shapiro (from July 1993 BYTE article, and the supporting source code)
  1979.  
  1980. // Saves the current value of A4 on the stack, and puts the address of main
  1981. // into A4. Should be called at start of stand-alone code resource to
  1982. access globals.
  1983. #define GetGlobals()    asm {                                        \
  1984.                         move.l      A4, -(SP)      ; save old A4        \
  1985.                         lea      main, A4       ; get globals        \
  1986.                         }
  1987.  
  1988.  
  1989. // The converse of GetGlobals(). Restore the value of A4                
  1990. #define UngetGlobals()     asm {                                     \
  1991.                         move.l      (SP)+, A4      ; restore A4 from stack \
  1992.                         }
  1993.  
  1994. This is dependent on main being at the beginning of your code resource and
  1995. on your compiler compiling the code resource using A4 addressing.
  1996.  
  1997. -- 
  1998. Brian  Stern  :-{)}
  1999. Jaeger@fquest.com
  2000.  
  2001. +++++++++++++++++++++++++++
  2002.  
  2003. >From bjaques@vanbc.wimsey.com (Barton Jaques)
  2004. Date: Fri, 19 Aug 1994 09:36:35 -0700
  2005. Organization: Wimsey Information Services
  2006.  
  2007. I spent many long hours slaving over my hot jGNEFilter before it worked
  2008. correctly. It is the sloppiest hack I've seen in a while, but it works
  2009. great. In short, here's what I do:
  2010.  
  2011. ¥ I have a separate jGNEFilter.’ project which compiles into a single
  2012. resource.
  2013. ¥ My INIT or DRVR reads that resource, detaches it, locks it.
  2014. ¥ At startup time, my INIT or DRVR reads the current value of jGNEFilter,
  2015. pokes it into my patch resource, then sticks the address of my patch
  2016. resource into jGNEFilter.
  2017. ¥ I have another handle which contains useful "global" variables and
  2018. pointers to procedures contained in other code resources. I poke the handle
  2019. into my detached jGNE resource. This way I have access to "globals" which I
  2020. have scattered through different code resources É yet I don't have to
  2021. fiddle with A5.
  2022. ¥ The way I do this is by initialising a couple of local variables in my
  2023. patch resource as follows:
  2024.      globRecH     globalsH = 0xEEEEEEEE;
  2025.      long            nextGNEFilter = 0xDDDDDDDD;
  2026.   My INIT or DRVR scans the resource, finds 0xEEEEEEEE, and overwrites it
  2027. with my "globals" handle. Then it scans for 0xDDDDDDDD, and overwrites it
  2028. with the pointer to the next GNE filter.
  2029. ¥ If my GNEFilter calls a procedure in another of my code resources, THEN I
  2030. need to set up A4/A5 as appropriate, and put it back before I return to my
  2031. patch.
  2032. ¥ When I want to de-install my driver, etc., I cauterise my patch by
  2033. plugging 0x00000000 where my globals handle was. The filter then knows that
  2034. it has been deactivated, so it passes to the next filter without doing
  2035. anything. I can always restore the patch simply by poking globH back in
  2036. again.
  2037.  
  2038.   This is the code in THINK C 68K. It surely will not work under another
  2039. environment without serious modification, but it should illustrate the
  2040. idea. 
  2041.  
  2042. void 
  2043. main() {
  2044.  
  2045.     globRecH        globH    = (globRecH)0xEEEEEEEE;
  2046.     long            nextGNEFilter = 0xDDDDDDDD;
  2047.     EventRecord *filteredEventP;
  2048.   // declare any other local vars you need
  2049.     Ptr            stackP;                            // stackP MUST be last local var declared
  2050.     
  2051.     //    move.l    (a7), -(a7)                        ; In actual res this line must precede LINK A6
  2052.     //                                                    ; In ResEdit, insert '2F17' as 1st word in res
  2053.     //                                                    ; then move 2nd-last byte (= 4E5E) to
  2054.     //                                                    ; precede 5th-last byte (= 4A97)
  2055.  
  2056.     asm{
  2057.         movem.l    a7, stackP                        ; make copy of stack pointer
  2058.         movem.l    a0-a3/d0-d7, -(sp)            ; save registers
  2059.     }            
  2060.     
  2061.     // if nextGNEFilter exists we must fiddle with stack to insert it
  2062.     if (nextGNEFilter) {
  2063.         stackP += ((Ptr)&globH - (Ptr)&stackP) + 8;
  2064.         *(long*)stackP = nextGNEFilter;
  2065.     }
  2066.     
  2067.     // do nothing if no globals
  2068.     if (globH) {
  2069.   // get a pointer to the event record
  2070.         asm{
  2071.             move.l    a1, filteredEventP            ; test a1 (EventPtr)
  2072.         }
  2073.         eventwhat = filteredEventP->what;
  2074.  
  2075.   // now we can do our stuff
  2076.     }
  2077.  
  2078.     // restore registers and stack
  2079.     asm{
  2080.         movem.l    (sp)+, d0-d7/a0-a3        ; restore all registers
  2081.         tst.l        (sp)                            ; in actual res these lines follow UNLK A6 (see note
  2082. above)
  2083.         bne        @END                            ; 
  2084.         tst.l        (sp)+                            ;
  2085.         @END
  2086.     }
  2087.  
  2088.     // control now passes to next GNEFilter handler if any
  2089. }
  2090.  
  2091.  
  2092. -- 
  2093. bjaques@vanbc.wimsey.com
  2094.  
  2095. +++++++++++++++++++++++++++
  2096.  
  2097. >From gurgle@dnai.com (Pete Gontier)
  2098. Date: Fri, 19 Aug 1994 12:20:28 -0800
  2099. Organization: Integer Poet Software
  2100.  
  2101. In article <bjaques-190894093636@pme22.pomo.wis.net>,
  2102. bjaques@vanbc.wimsey.com (Barton Jaques) wrote:
  2103.  
  2104. > I spent many long hours slaving over my hot jGNEFilter before it worked
  2105. > correctly. It is the sloppiest hack I've seen in a while, but it works
  2106. > great. In short, here's what I do...
  2107.  
  2108. With all due respect for your long hours, quite frankly this all seems
  2109. very convoluted and mildly dangerous. If any step in the development
  2110. process goes wrong, the program fails at runtime. There are a minimum of
  2111. helpful compile-time checks, and it's difficult to see why any one part of
  2112. it works the way it does without understanding the whole picture. I'm glad
  2113. it works for you, but it seems a lot simpler and a lot cleaner to simply
  2114. use a strategy like that illustrated in "jGNE Helper" or whatever the hell
  2115. that monthly posting is called. (It may sound like I didn't write it
  2116. because I can't even remember its name, but I did write it, and you should
  2117. assume I am accordingly biased.)
  2118.  
  2119. -- 
  2120.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  2121.  
  2122.  "Even during a particularly harsh (Colorado) winter... many of the
  2123.  300 families in the VCTV (movies-on-demand) trial continued to go
  2124.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  2125.  
  2126. +++++++++++++++++++++++++++
  2127.  
  2128. >From Jaeger@fquest.com (Brian Stern)
  2129. Date: 20 Aug 1994 00:25:40 GMT
  2130. Organization: The University of Texas at Austin, Austin, Texas
  2131.  
  2132. In article <bjaques-190894093636@pme22.pomo.wis.net>,
  2133. bjaques@vanbc.wimsey.com (Barton Jaques) wrote:
  2134.  
  2135. > I spent many long hours slaving over my hot jGNEFilter before it worked
  2136. > correctly. It is the sloppiest hack I've seen in a while, but it works
  2137. > great. In short, here's what I do:
  2138.  
  2139. Or, you could simply use A4 addressing to access your globals from your
  2140. Filter.  You can easily set a Boolean flag to let your Filter know if it's
  2141. supposed to do anything.  
  2142.  
  2143. I don't trust any code building method that has instructions in it like '
  2144. In ResEdit, insert '2F17' as 1st word in res then move 2nd-last byte (=
  2145. 4E5E) to precede 5th-last byte (= 4A97)'.
  2146.  
  2147. In programming like in most things simpler is usually better.  There are
  2148. lot's simpler ways to do it than this.
  2149.  
  2150. > -- 
  2151. > bjaques@vanbc.wimsey.com
  2152.  
  2153. -- 
  2154. Brian  Stern  :-{)}
  2155. Jaeger@fquest.com
  2156.  
  2157. +++++++++++++++++++++++++++
  2158.  
  2159. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  2160. Date: 20 Aug 94 17:24:09 GMT
  2161. Organization: Stanford University: Computer Science Department
  2162.  
  2163. larson@oahu.cs.ucla.edu (Christopher Larson) writes:
  2164.  
  2165. >In article <jedavis.777289328@Xenon.Stanford.EDU> jedavis@Xenon.Stanford.EDU (James Edward Davis) writes:
  2166. >>Jaeger@fquest.com (Brian Stern) writes:
  2167.  
  2168. >Well, you could use the above strategy, or if that is still to self-modify-
  2169. >ish, you could install a Gestalt selector. Note that trickery to recover your
  2170. >A5 is only necessary if your code might run when your app is switched out or
  2171. >at interrupt time. If this is not the case, you can recover it from CurrentA5,
  2172. >as you suggested earlier. 
  2173.  
  2174. >Hmmm. This raises an interesting question. If an app installs a jGNEFilter,
  2175. >is that filter visible to all other applications, or is it more like trap
  2176. >patches (which, if done from an app, are only visible to the installing app)?
  2177. >Anyone?
  2178.  
  2179. The jGNE filter *is* active across all apps. The low memory global that
  2180. points to the filter chain, is not changed by context switches. This
  2181. means you have to be very careful if you install a filter with code
  2182. in your app heap, since if you quit without cleanup, theres a dangling
  2183. reference and the machine will crash.
  2184.  
  2185. -James
  2186.  
  2187.  
  2188. +++++++++++++++++++++++++++
  2189.  
  2190. >From kluev@jonathan.srcc.msu.su (Kluev)
  2191. Date: Mon, 22 Aug 94 23:02:46 +0400
  2192. Organization: (none)
  2193.  
  2194. In article <jedavis.777403449@Xenon.Stanford.EDU>
  2195. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2196.  
  2197. > The jGNE filter *is* active across all apps. The low memory global
  2198. that
  2199. > points to the filter chain, is not changed by context switches. This
  2200. > means you have to be very careful if you install a filter with code
  2201. > in your app heap, since if you quit without cleanup, theres a
  2202. dangling
  2203. > reference and the machine will crash.
  2204.  
  2205. One should be careful about this cleanup. One shouldn't restore
  2206. original value in jGNEFilter, because someone may install gne
  2207. filter on top of one's. Restoring jGNEFilter to original value
  2208. will remove someone's filter and may crash him. The better
  2209. solution is to install one's filter into system heap, never
  2210. remove it, check if filter was already installed (Gestalt is
  2211. one solution) (not to install it twice), set/clear flag on
  2212. application's startup/exit to turn filter's activity on/off.
  2213.  
  2214. Michael Kluev.
  2215.  
  2216. +++++++++++++++++++++++++++
  2217.  
  2218. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  2219. Date: 23 Aug 94 02:50:02 GMT
  2220. Organization: Stanford University: Computer Science Department
  2221.  
  2222. kluev@jonathan.srcc.msu.su (Kluev) writes:
  2223.  
  2224. >In article <jedavis.777403449@Xenon.Stanford.EDU>
  2225. >jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2226.  
  2227. >One should be careful about this cleanup. One shouldn't restore
  2228. >original value in jGNEFilter, because someone may install gne
  2229. >filter on top of one's. Restoring jGNEFilter to original value
  2230. >will remove someone's filter and may crash him. The better
  2231. >solution is to install one's filter into system heap, never
  2232. >remove it, check if filter was already installed (Gestalt is
  2233. >one solution) (not to install it twice), set/clear flag on
  2234. >application's startup/exit to turn filter's activity on/off.
  2235.  
  2236. Yes, that would work but Id rather not leave memory allocated
  2237. in the system heap. But your right about another being installed
  2238. over mine. I allocate a small block in the system heap that just
  2239. jumps to my code in the application heap. When I want to deinstall,
  2240. I check to see if the front jGNEfilter is me. If it is, I can 
  2241. just reset the pointer. If its not, I change my stub to 
  2242. jump to the original address instead of my code. I only end up
  2243. wasting a little system heap that way. I cant claim credit 
  2244. for the technique. I got a snippet from someone else, thought
  2245. it was clever, and used it.
  2246.  
  2247. -James
  2248.  
  2249. +++++++++++++++++++++++++++
  2250.  
  2251. >From h+@nada.kth.se (Jon W{tte)
  2252. Date: Tue, 23 Aug 1994 09:49:02 +0200
  2253. Organization: Royal Institute of Something or other
  2254.  
  2255. In article <jedavis.777610202@Xenon.Stanford.EDU>,
  2256. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2257.  
  2258. >Yes, that would work but Id rather not leave memory allocated
  2259. >in the system heap. But your right about another being installed
  2260. >over mine. I allocate a small block in the system heap that just
  2261. >jumps to my code in the application heap. When I want to deinstall,
  2262.  
  2263. I hope you remember to flush the cache when you change this 
  2264. value...
  2265.  
  2266. Cheers,
  2267.  
  2268.                 / h+
  2269.  
  2270.  
  2271. --
  2272.   Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  2273.   "Psychotherapist" - "Phycho-The-Rapist"
  2274.    Pure coincidence? You decide!
  2275.  
  2276.  
  2277. +++++++++++++++++++++++++++
  2278.  
  2279. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  2280. Date: 23 Aug 94 22:00:51 GMT
  2281. Organization: Stanford University: Computer Science Department
  2282.  
  2283. h+@nada.kth.se (Jon W{tte) writes:
  2284.  
  2285. >In article <jedavis.777610202@Xenon.Stanford.EDU>,
  2286. >jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2287.  
  2288. >>Yes, that would work but Id rather not leave memory allocated
  2289. >>in the system heap. But your right about another being installed
  2290. >>over mine. I allocate a small block in the system heap that just
  2291. >>jumps to my code in the application heap. When I want to deinstall,
  2292.  
  2293. >I hope you remember to flush the cache when you change this 
  2294. >value...
  2295.  
  2296. Why.. thats an excellent point. I dont flush it, but it seems to
  2297. work fine on my C610. I think Ive been very lucky.. Ill go change
  2298. that. Unless anyone can think of a legit reason its working.
  2299.  
  2300. Thanks,
  2301. James
  2302.  
  2303. +++++++++++++++++++++++++++
  2304.  
  2305. >From kluev@jonathan.srcc.msu.su (Kluev)
  2306. Date: Wed, 24 Aug 94 21:13:06 +0400
  2307. Organization: (none)
  2308.  
  2309. In article <jedavis.777679251@Xenon.Stanford.EDU>
  2310. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2311.  
  2312. > h+@nada.kth.se (Jon W{tte) writes:
  2313. > >In article <jedavis.777610202@Xenon.Stanford.EDU>,
  2314. > >jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2315. > >>Yes, that would work but Id rather not leave memory allocated
  2316. > >>in the system heap. But your right about another being installed
  2317. > >>over mine. I allocate a small block in the system heap that just
  2318. > >>jumps to my code in the application heap. When I want to deinstall,
  2319. > >I hope you remember to flush the cache when you change this 
  2320. > >value...
  2321. > Why.. thats an excellent point. I dont flush it, but it seems to
  2322. > work fine on my C610. I think Ive been very lucky.. Ill go change
  2323. > that. Unless anyone can think of a legit reason its working.
  2324.  
  2325. This depends on processor type and what your code is looked like.
  2326.  
  2327. If it is looked like that:
  2328.   JMP Address; 0x4EF9 0x12345678; where 0x12345678 is modified address,
  2329. you need to flush cache on 040 processors.
  2330.  
  2331. If it is looked like this:
  2332.   MOVE.L *+$0006, -(sp); 0x2F3A0004;
  2333.   RTS;                   0x4E75
  2334.   DC.L 0x12345678;       0x12345678; where 0x12345678 is modified addr,
  2335. don't worry about flushing cache. (DC.L will not run as code.)
  2336.  
  2337. /* From MacTech magazine */
  2338.  
  2339. Michael Kluev.
  2340.  
  2341. ---------------------------
  2342.  
  2343. End of C.S.M.P. Digest
  2344. **********************
  2345.  
  2346.  
  2347.  
  2348.